It’ll probably be much easier if someone familiar with gstreamer knows of a simple way to determine if the NVIDIA accelerated libraries are used in a particular pipeline, but I’ll give some information below on the more complicated part of the topic. Hopefully someone familiar with gstreamer will have a quick/easy way to know if H.264 in a given pipeline is hardware accelerated or not.
Almost all user space software will be dynamically linked against libraries, e.g., any “hello world” type application will use libc. The “strace” tool traces system calls to the kernel…these are function calls which don’t go to a library (this is the communications the program uses directly to the kernel). The ltrace tool traces library calls (and it is a library call which might optionally go to an NVIDIA hardware accelerated file versus a generic CPU-only file). These tools work on a running program and produce a LOT of output (think of it as a list of every function call which goes outside of the program, along with categorizing as either a call to the kernel or a call to a library). So ltrace would tell you about library calls. For an example, assuming “ls” is at “/usr/bin/ls”:
(the information is about what was passed to/from a library for individual function calls)
To statically determine what an executable file links to for a library (without needing to look at individual function calls) you would use ldd. Example:
Notice that ldd names libraries which are part of the system linker path. To see where the system linker looks to find those libraries:
(when ldd tells you which library it uses ldconfig can then be invoked to cross-reference where the file is physically located on the file system)
It is also possible that a program can dynamically load a plugin style module which won’t show up under ldd (it isn’t the system linker path used for loading…loading takes place during runtime by an explicit request to link to a file), although ltrace would show the function calls. This is basically because a library can call another library, and ldd does not recurse into other libraries. This is also why extracting this information under gstreamer might be difficult…some of it loads as a module and is not directly incorporated into gstreamer (thus ldd might not show the linking).
To demonstrate a library calling another library assume “ldconfig -p” shows libc.so.6 is located at “/lib64/libc.so.6” (this is where one Linux PC desktop distribution puts the file…it may differ on your system):
> ldd /lib64/libc.so.6
This implies that libc.so.6 is linked to, and makes calls to, ld-linux-x86-64.so.2 and linux-vdso.so.1 on this particular system. If you found a particular library or module which your gstreamer uses to provide the H.264 functions, then you could run ldd on it and determine if the file used to fulfill that function is NVIDIA’s hardware accelerated version, or if the file is a CPU-only version. You could run ltrace on your pipeline and perhaps get a clue to what library to look for, but that would be a LOT of work.
So…this is why I’m asking if anyone familiar with gstreamer knows a way to quickly determine if a given gstreamer pipeline uses a hardware accelerated NVIDIA version of H.264.