Subsections

- Hardware decoding in CINELERRA-GG
- Possible improvements or differences
- Special .opts file
- To verify hardware acceleration
- Case 1:
- Case 2:

##
GPU hardware decoding

1. Verify that you have installed libva-dev or libva on your operating system.
2. Verify that you have installed libva-intel-driver on your operating system
3. Verify that you also have libvdpau-dev or libvdpau installed.
4. Verify Settings → Preferences, Playback tab, Video Driver is set to X11 – or X11-OpenGL if that produces better results for your configuration.
5. Before starting CINELERRA-GG, you can set an environment variable that can be easily reversed and then, to run from the CINELERRA-GG installed directory, key in:

    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

and substituting your specific location instead of /dev/dri/renderD129 or D128.

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

###
Hardware decoding in CINELERRA-GG

There are 4 phases during CINELERRA-GG’s handling of hardware acceleration. These first 2 steps occur just before the first read.

1. Check to see if Hardware Acceleration is enabled, usually indicated by CIN_HW_ _DEV being set to vaapi or vdpau. If enabled, try to activate the decode device, and if that fails revert to software.
2. The next step is to send some data to decode to see if that works. If this does not work, you will see an error message of HW device init failed, using SW decode.

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.

1. Read the media and send the raw stream data to the device for processing.
2. Read the device to receive the decoded data, and convert it to the session color model. If the GPU can not convert the data, you will see the error message of Error retrieving data from GPU to CPU.

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:

- Hardware acceleration, vaapi or vdpau, works the same running either the created binary or the created AppImage from that binary on that same computer. See Build the CinGG.AppImage from scratch.
- Hardware acceleration using an AppImage created on another computer running a different Operating System or even just a different level of Operating System, most likely will not work unless the user’s computer just happens to have the same characteristics with respect to vaapi/vdpau as the computer where the AppImage was created.

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.

###
Possible improvements or differences

1. The Frames Per Second (FPS) in playback might usually be at the maximum rate. You can check this in Settings → Preferences, Playback A, looking at Framerate achieved; the higher, the better.
2. Percent of the CPU used should be less, thus saving more CPU for other operations.
3. Some users get the the impression that playing seems smoother.
4. The CPU fan noise may go down as the CPU is used less.
5. The GPU graphics fan noise may go up as the GPU is used more.

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:

- If you only use smaller videos occasionally and then use other codecs than the ones mentioned previously as being the optimized set, it is usually a better idea to stay with the default settings without all the hardware tests.
- If you have 4 cores or less, but a really good gaming card, using vaapi/vdpau could be a big help.
- If you load only a couple of files, the GPU vaapi/vdpau should be faster depending on your graphics board and how capable it is.
- If you load 10 camera Mixers of H.264 format, it always seems to work a lot better playing them.
- If you have an epyc AMD chip with 128 CPUs and load 50 files, without vaapi/vdpau may be better.

###
Special .opts file

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

Conversely, if you have a bunch of files in your project, like dnxhd format, that are not hardware accelerated, but you have an accompanying large file of type .mp4 for which you would like the hardware acceleration, you can leave the CIN_HW_DEV variable unset (that is, do not use it) and just create an .opts file containing the line:

    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.

###
To verify hardware acceleration

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.

###
Case 1:

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.

###
Case 2:

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.