Next: GPU hardware encoding Up: Hardware video acceleration Previous: Hardware video acceleration Contents Index
CIN_HW_DEV=vdpau ./cin # for computers with Nvidia and some other graphics cards CIN_HW_DEV=vaapi ./cin # mostly for computers with Intel or AMD specific graphics hardware |
If you find that the environment variable setting is advantageous for your CinGG usage and you want to always use it, you can add it in your $HOME directory .profile file which takes effect every time you log in. The line you would add would look something like this:
export CIN_HW_DEV=vdpau or export CIN_HW_DEV=vaapi |
In addition for a computer with dual graphics cards, you can select your specific device with an environment variable to decode and encode. For example:
CIN_DRM_DEC=/dev/dri/renderD129 CIN_DRM_ENC=/dev/dri/renderD128 ./cin |
It might be more difficult to analyze problems as a result of using the GPU because of the wide variation in hardware. When you do not set the CIN_HW_DEV environment variable, the code will work exactly as before since this feature is self-contained.
There is also a Settings → Preferences, Performance tab, Use HW device flag with a pulldown to set up none, vdpau, vaapi, or cuda. To ensure it takes effect, it is best to set it the way you want, quit out of CINELERRA-GG and then restart. Its current purpose is for flexibility, but there is a possibility that it might eventually take the place of CIN_HW_DEV – both are not needed.
Precedence of the decode hardware acceleration settings are:
– yourfile.opts is checked first so is of the highest priority; special .opts usage is described below
– environment variable CIN_HW_DEV is checked next
– preferences Use HW device settings is of the lowest priority
These next 2 steps occur during any read. Now there is no turning back to software so if the hardware gets an error, that video will not be handled correctly.
AppImage will probably not allow for either VDPAU or VA-API hardware acceler- ation because the computer where AppImage is created will not have the same graphics card and/or vaapi/vdpau libraries as yours. In other words:
Due to these variations in user’s computer hardware configuration, it is often suggested that you refer to your startup window to check for error messages. Since your situation is unique, the error may not have been seen by anyone else and is probably unknown/undocumented. For debugging problems, modify in the CINELERRA-GG ffmpeg subdirectory, the file: decode.opts by temporarily changing the line from loglevel =fatal to loglevel =verbose and restarting CINELERRA-GG.
Using the GPU is going to react differently depending on your hardware, software, and the number of files loaded. A good way to determine how well it is performing, is to watch the CPU load from another window running the command line routine top. Consider the following possibilities:
The situation may arise where you have enabled hardware acceleration and after loading several files for a project, you find that a file had some kind of error resulting in a black video instead of an image or you see an error message pop up which states something like Error retrieving data from GPU to CPU or err: Unknown error occurred. Because the CIN_HW_DEV environment variable is either all or none, ordinarily in order to correct the non-working video you would have to turn off hardware acceleration for the entire project/session. However, there is a way to continue working on your project without having to reload all of your files. You still use the environment variable and it will be effective for all of the formats it is able to handle, but you make an exception for any of the files that erred out. To do this you simply create a file in the same directory with the same name as the erring file with the different extension of .opts. The contents of this .opts file would just be the one line of:
cin_hw_dev=none |
cin_hw_dev=vdpau |
For example your file, test.mp4, would have a side-kick called test.opts that will use the GPU for decoding/playing and the other files will just use the software. This is of some advantage because the ones that can not use the GPU if the environment variable is enabled, will not have to even check which saves a minuscule bit of time.
It is important to note that if using the .opts file to override the default ffmpeg / decode.opts file, you will most likely see more warnings (not really errors) in the CINELERRA-GG startup window because the standard decode.opts file has loglevel = fatal whereas the default is loglevel = error. To avoid seeing all of the extra warnings, you can simply add the line loglevel=fatal to your .opts file.
Probably the easiest way to tell if hardware acceleration is working, is just to look at the messages in the window from where you started Cin (not available if start using the application icon). For example load a png, dnxhd, or some other non-supported format file and you will see messages similar to those below. The line HW device init failed, using SW decode indicates that the vdpau/vaapi HW (hardware) decode is not available so will use SW (software) decode instead.
Failed to get HW surface format. HW device init failed, using SW decode. file:/tmp/media/aer_zypr.mp4 err: Success or Decoder dnxhd does not support device type vdpau. HW device init failed, using SW decode. File:/tmp/media/test.gxf err: Success or HEVC with NVIDIA, VDPAU driver is buggy, skipping |
AppImage does not provide this capability. If you would like to see more information on what is occurring, you can modify in the CINELERRA-GG ffmpeg subdirectory, the file: decode.opts by temporarily changing the line from loglevel =fatal to loglevel =verbose and restarting CINELERRA-GG. Then you will see messages in the startup window like:
[AVHWDeviceContext @ 0x7fc9540be940] Successfully created a VDPAU device (NVIDIA VDPAU Driver Shared Library 390.116 Sun Jan 27 06:28:58 PST 2019) on X11 display :0 [h264 @ 0x7fc950159380] Reinit context to 1920x1088, pix_fmt: vdpau [h264 @ 0x7fc92c3dd4c0] Reinit context to 1920x1088, pix_fmt: yuv420p |
Again, to measure the performance run top from another window to check the CPU usage which will go lower as more work is offloaded to the GPU graphics card instead (it may go down by 2 to 10 times) or check the Framerate achieved while playing.
Some mixed preliminary results that have been reported are provided below.
X11 Video Driver set in Settings → Preferences, Playback A tab:
| CIN_HW_DEV=off ./cin | CPU 58% | |
| CIN_HW_DEV=vdpau ./cin | CPU 32% | |
| CIN_HW_DEV=vaapi ./cin | CPU 82% |
X11-OpenGL Video Driver set in Settings → Preferences, Playback A tab:
| CIN_HW_DEV=off ./cin | CPU 48% | |
| CIN_HW_DEV=vdpau ./cin | CPU 12% | |
| CIN_HW_DEV=vaapi ./cin | CPU 80% |
Best is the least amount of CPU usage. Note that in this Case 1, using the X11-OpenGL video driver is better than using the X11 video driver.
X11 Video Driver set in Settings → Preferences, Playback A tab:
| CIN_HW_DEV=off ./cin | CPU 60% | |
| CIN_HW_DEV=vdpau ./cin | CPU 11% | |
| CIN_HW_DEV=vaapi ./cin | CPU 60% |
X11-OpenGL Video Driver set in Settings → Preferences, Playback A tab:
| CIN_HW_DEV=off ./cin | CPU 67% | |
| CIN_HW_DEV=vdpau ./cin | CPU 60% | |
| CIN_HW_DEV=vaapi ./cin | CPU 67% |
Best is the least amount of CPU usage. Note that in this Case 2, using the X11 video driver is better than using the X11-OpenGL video driver.
Older graphics cards or non-performing graphics cards will probably bring only a small amount of improvement or no speed advantage at all. You can check to see if vdpau is implemented for your specific Nvidia board at:
https://download.nvidia.com/XFree86/Linux-x86_64/304.137/README/supportedchips.html
And, you can see what your specific hardware and software might support by running either vainfo (available in the libva-utils package) or vdpauinfo (available in the vdpauinfo package) from the command line. For example which "Profiles" your hardware can handle is listed in the output such as Main and High. Partial examples of each are shown below.
# vainfo vainfo: VA-API version: 1.4 (libva 2.4.0) vainfo: Driver version: Intel i965 driver for Intel(R) Broadwell - 2.4.0.pre1 (2.3.0-11-g881e67a) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple ... VAProfileH264Main VAProfileH264High ... VAProfileH264MultiviewHigh VAProfileH264StereoHigh ... VAProfileVC1Simple ... VAProfileVP8Version0_3 |
# vdpauinfo display: :0 screen: 0 API version: 1 Information string: G3DVL VDPAU Driver Shared Library version 1.0 ... Decoder capabilities: name level macbs width height ---------------------------------------------------- MPEG1 --- not supported --- MPEG2_SIMPLE 3 65536 4096 4096 MPEG2_MAIN 3 65536 4096 4096 H264_BASELINE 52 65536 4096 4096 H264_MAIN 52 65536 4096 4096 H264_HIGH 52 65536 4096 4096 VC1_SIMPLE 1 65536 4096 4096 VC1_MAIN 2 65536 4096 4096 VC1_ADVANCED 4 65536 4096 4096 |
One last item of note, nvdec is also enabled in the ffmpeg build, but at this time it is not known how this decode option on Nvidia graphics boards works or does not work in conjunction with vdpau.