Video transcoding using codecs and interfacing them with your software

Discussion in 'C' started by uengin, Mar 2, 2010.

  1. uengin

    uengin New Member

    Joined:
    Mar 1, 2010
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    I am a last year electronic engineering student. I have had some programming experience but not a whole heap. I am very practical, so I learn by examples very well.

    I am in a project in a company where I need to implement transcoding from one format to another. Now, so far, I am under the impression that I get the relative codecs, and use them to decode and re-encode reading from the file or stream.

    As I said I haven't had much experience and I am very practical so I lean by doing and examples, so from my research so far I have not been able to understand how I use a binary library file (I am working in linux btw) and interface my code with the binary library. I believe this is where API's come in right? Am I going in the right direction? Can anyone direct me to resourses, tutorials, examples or explanations for this application? Or can you give me semi-detailed explanation of how this might be done? :confused

    Thank you so much in advance. Really appreciate it.
     
  2. xpi0t0s

    xpi0t0s Mentor

    Joined:
    Aug 6, 2004
    Messages:
    3,009
    Likes Received:
    203
    Trophy Points:
    63
    Occupation:
    Senior Support Engineer
    Location:
    England
    A library implements an API. For example printf() is part of the file I/O API, and it is implemented by the C runtime library. Similarly sin cos tan are part of the math API, and are implemented by libm.a. So this has two implications for your application: (1) your code must #include the relevant header file (which defines the API) and (2) your executable must be linked with the relevant library.

    Code:
    #include <math.h>
    #include <stdio.h>
    
    int main()
    {
      double x=30;
      double sinx=sin(x);
      printf("sin of %e is %e\n",x,sinx);
      return 0;
    }
    
    gcc -c test.c -o test.o   // compile test.c to object
    gcc test.o libm.a -o test    // link test.o and libm.a together to make test executable
    
    or in one step
    gcc test.c -lm -o test
    
    Not tested so I might have missed something obvious, but that's the gist of it.

    The linker has a shortcut -l where if you specify -lX, the linker goes off in search of libX.a (where X is anything). So libm.a can be abbreviated -lm.
     
  3. uengin

    uengin New Member

    Joined:
    Mar 1, 2010
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    Thank you for your reply xpi0t0s.

    That you have explained I am aware of but what I want to know is lest say I write a code that loads a video file. It is in wrapped in some format and compressed with some codec, for arguments sake mpeg4 for the video and mpeg4-L3 for audio. and in order to decode this I am using the library libffmpeg.so. Now, that library is already compiled and in binary. How do find out what functions are contained in that library? How do I use the functions contained in that library and how do I link to it?

    Again, thanks in advance.
     
  4. xpi0t0s

    xpi0t0s Mentor

    Joined:
    Aug 6, 2004
    Messages:
    3,009
    Likes Received:
    203
    Trophy Points:
    63
    Occupation:
    Senior Support Engineer
    Location:
    England
    You can't usually tell just by looking at the library. You need the header file as well. Then you can find out what functions are in the library by looking at the header file and reading the documentation.

    How do you use the functions: as explained above. Let's say libffmpeg.so contains a compiled function void LoadFile(char *fileName). In the header file (let's call it libffmpeg..h) there will be a line:
    Code:
    void LoadFile(char *fileName);
    
    Then your code needs (a) to include that header file:
    Code:
    #include "libffmpeg.h"
    
    (b) call the function:
    Code:
    void myFunc(char *fnam)
    {
      LoadFile(fnam);
    }
    
    and (c) to link with the library to avoid "undefined symbol" errors:
    Code:
    gcc test.c libffmpeg.so -o test
    
     
  5. uengin

    uengin New Member

    Joined:
    Mar 1, 2010
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    Aaaahaa. Excellent! thank you so much. The fact that you used examples to explain it to me made all the difference. Thank you so so so much.

    So as a very very short summary, in order to know and use the functions of a library, you need the header file that created the header file in the first place which has all the functions in it anyway. (?) but you dont have to recompile the library.

    Also, dynamically linking the new software, will make it look for the systems library folder when it's running (and complain if it's not there) ?
     
  6. xpi0t0s

    xpi0t0s Mentor

    Joined:
    Aug 6, 2004
    Messages:
    3,009
    Likes Received:
    203
    Trophy Points:
    63
    Occupation:
    Senior Support Engineer
    Location:
    England
    I've no idea what a "header file that created the header file in the first place" is. When a library developer publishes a library, they will typically release the binary library and a header file that defines the functions implemented by the library. They won't necessarily have used the header file to compile the library.

    You don't even need to use the header file the developer released. All the compiler needs to know is the function prototype, and the linker needs to be able to find the symbol. So you could just stick "void LoadFile(char *fileName);" in at the top of test.c and it'll work fine. However it's usually more hassle to do that, and doesn't really provide many benefits, which is why we just take the easy way and #include "libffmpeg.h".

    You certainly don't have to recompile a library in order to be able to use it. Linux nerds frequently want to, which is why "how to recompile the library" is usually on something like page 1 of the documentation instead of hidden in an appendix. But nobody would be able to release closed-source libraries if recompiling was necessary.

    Dynamic linking doesn't make the software do anything you didn't specify. At runtime the program will attempt to load the shared library from PATH, LD_LIBRARY_PATH and/or SHLIB_PATH, depending on OS and how much of this I've got right, and the only complaint you'll get is if the library itself doesn't exist. It doesn't matter if any of those PATHs point to nonexistent locations.
     
  7. uengin

    uengin New Member

    Joined:
    Mar 1, 2010
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    Sorry by bad, that was meant to say "the header file that created the library binary file". But anyway, that was very helpful. Thanks a lot champ. I really appreciate it. You have been very helpful. :happy:
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice