VideoHelp Forum
+ Reply to Thread
Results 1 to 7 of 7
Thread
  1. I just tried ffmpeg 5.0

    As usual, the developers have made incompatible changes to some commands (which they claim makes them more compatible).

    Specifically, the syntax for enabling and using QSV acceleration have changed.

    For quite some time, this command worked:

    ffmpeg -hide_banner -init_hw_device qsv=qsv -hwaccel qsv (vsync if needed) -i "input file" -c:a (audio encode or copy)
    --c:v h264_qsv -preset (various options, vpp_qsv filters, other filters, etc) -q:v NN (to set quality) "output file.mp4"

    I just tried this same command with 5.0, and get:

    ---

    WARNING: defaulting child_device_type to AV_HWDEVICE_TYPE_DXVA2 for compatibility with old commandlines. This behaviour will be removed in the future. Please explicitly set device type via "-init_hw_device" option.

    WARNING: defaulting hwaccel_output_format to qsv for compatibility with old commandlines. This behaviour is DEPRECATED and will be removed in the future. Please explicitly set "-hwaccel_output_format qsv".

    ---

    The first error is the big one. I can't find a syntax that will satisfy ffmpeg, and the documentation has no examples that work.

    It would appear that this should work:

    I:\Downloads>ffmpeg -hide_banner -init_hw_device qsv:auto -hwaccel qsv -hwaccel_output_format qsv -vsync auto -i "input"
    -c:v h264_qsv -preset veryslow (etc.) "output.mp4"

    but I still get:

    WARNING: defaulting child_device_type to AV_HWDEVICE_TYPE_DXVA2 for compatibility with old commandlines. This behaviour will be removed in the future. Please explicitly set device type via "-init_hw_device" option.

    The documentation web site https://ffmpeg.org/ffmpeg.html says the following:

    -init_hw_device type[=name][:device[,key=value...]]

    Initialise a new hardware device of type type called name, using the given device parameters. If no name is specified it will receive a default name of the form "type%d".

    The meaning of device and the following arguments depends on the device type:

    cuda

    device is the number of the CUDA device.

    The following options are recognized:

    primary_ctx

    If set to 1, uses the primary device context instead of creating a new one.

    Examples:

    -init_hw_device cuda:1

    Choose the second device on the system.
    -init_hw_device cuda:0,primary_ctx=1

    Choose the first device and use the primary device context.

    dxva2

    device is the number of the Direct3D 9 display adapter.
    d3d11va

    device is the number of the Direct3D 11 display adapter.
    vaapi

    device is either an X11 display name or a DRM render node. If not specified, it will attempt to open the default X11 display ($DISPLAY) and then the first DRM render node (/dev/dri/renderD128).
    vdpau

    device is an X11 display name. If not specified, it will attempt to open the default X11 display ($DISPLAY).
    qsv

    device selects a value in ‘MFX_IMPL_*’. Allowed values are:

    auto
    sw
    hw
    auto_any
    hw_any
    hw2
    hw3
    hw4

    If not specified, ‘auto_any’ is used. (Note that it may be easier to achieve the desired result for QSV by creating the platform-appropriate subdevice (‘dxva2’ or ‘d3d11va’ or ‘vaapi’) and then deriving a QSV device from that.)

    Alternatively, ‘child_device_type’ helps to choose platform-appropriate subdevice type. On Windows ‘d3d11va’ is used as default subdevice type.

    Examples:

    -init_hw_device qsv:hw,child_device_type=d3d11va

    Choose the GPU subdevice with type ‘d3d11va’ and create QSV device with ‘MFX_IMPL_HARDWARE’.
    -init_hw_device qsv:hw,child_device_type=dxva2

    Choose the GPU subdevice with type ‘dxva2’ and create QSV device with ‘MFX_IMPL_HARDWARE’.

    Maybe I'm obtuse, but I can't get these examples to work. A sub-device of 'dxva2' should not be needed, and is in fact undesirable as it would not use the QSV acceleration.

    Can anyone please explain the new, much more complex and complicated syntax in simple terms?


    ===

    I also got

    "Passing a number to -vsync is deprecated, use a string argument as described in the manual."

    but that was because the older version would not accept "auto" as input and required the numerical value of -1, contrary to documentation.

    But if I do say "auto", I get this:

    Expected number for vsync but found: auto

    So you get an error from -1 and an error from auto.

    I'd really appreciate an explanation for this, if anyone has one.
    Quote Quote  
  2. Yep... this is ffmpeg developers approach - faced this many times before...
    I can only advise to use source as documentation - some features or functionality has very sparse or sometimes no documentation at all so source is the only one that may be used as guidelines...
    Quote Quote  
  3. I've been doing some experimenting.

    This much appears to work.

    ffmpeg -hide_banner -init_hw_device qsv:hw,child_device_type=dxva2 -hwaccel qsv -hwaccel_output_format qsv [-vsync -1] -i "input"
    -c:v h264_qsv -preset [rest of video and audio settings, filters, etc] "output.mp4"

    This appears to enable both hardware decoding and encoding. There isn't a good way to measure this in Windows 7: I will try
    on Windows 10, the Task Manager GPU page can differentiate between encode and decode: however, the current QSV / Intel
    driver is missing an option to supply this information to Task Manager so it won't display the GPU page at all for the Intel CPU
    I have in my Windows 10 system. Perhaps Intel can do something to fix this. I can post more information if desired, but it
    should probably go into a separate topic.

    The -vsync problem is bugging me. Sometimes if I put in -vsync vfr I get errors, but the most recent time I tried it, it worked.
    However, specifying "auto" always fails, contrary to the documentation.

    The vpp_qsv filter error is also odd. Although I got an error message as I showed in my first post, it apparently did in fact
    do the scaling properly. So it's anybody's guess what's actually happening.

    I will do more experiments and report back if anyone is interested.
    Quote Quote  
  4. I should also have noted that the reason I'm going through all of this is that using the QSV codec results in a HUGE time saving over the default H264 codec.

    I have a Windows 10 system that also has a QSV capable CPU, and I had an Nvidia Quadro K620 card that supports CUDA in it. Both did hardware accelerated decode and encode, and the time needed to process a given video file was about the same for both choices. But the QSV codec does much, much better compression for the same quality video output than CUDA does. Also, CUDA doesn't have as many options, and the CUDA enhanced filters are an absolute nightmare to use. The examples on the Nvidia web site are just plain wrong: they don't work, and Nvidia just doesn't care. Their support forum was also no help at all. It's also just about impossible to mix CUDA and non-CUDA filters in the same ffmpeg pass, whereas QSV and non-QSV filters don't require anything special to work.

    This is why I want to help get these problems fixed: even with the most recent problems I'd very much rather work with Intel / QSV than Nvidia CUDA. I've even removed the Quadro board from the PC.
    Quote Quote  
  5. Originally Posted by BartZLederman View Post
    I will do more experiments and report back if anyone is interested.
    Of course people are interested so please share everything! Even if for today seem there is no huge feedback then for sure it will be useful in future for somebody.

    Originally Posted by BartZLederman View Post
    I have a Windows 10 system that also has a QSV capable CPU, and I had an Nvidia Quadro K620 card that supports CUDA in it. Both did hardware accelerated decode and encode, and the time needed to process a given video file was about the same for both choices. But the QSV codec does much, much better compression for the same quality video output than CUDA does. Also, CUDA doesn't have as many options, and the CUDA enhanced filters are an absolute nightmare to use. The examples on the Nvidia web site are just plain wrong: they don't work, and Nvidia just doesn't care. Their support forum was also no help at all. It's also just about impossible to mix CUDA and non-CUDA filters in the same ffmpeg pass, whereas QSV and non-QSV filters don't require anything special to work.

    This is why I want to help get these problems fixed: even with the most recent problems I'd very much rather work with Intel / QSV than Nvidia CUDA. I've even removed the Quadro board from the PC.
    It is very important, Intel offer QSV in pure HW and mix CPU+HW (hybrid) mode - hybrid mode usually deliver higher quality however Intel recently is quite silent on QSV. NVidia offers NVDec and NVEnc blocks - dedicated HW decoder and encoder (independent from GPU HW blocks), CUDA is just GPGPU (similar as OpenCL on Intel and others). So whenever you use CUDA it is not clear if you write about NVDec & NVEnc or GPGPU.
    Not even sure if there is video codec implementation for CUDA (OpenCL) - in past there was some tries to write such engines but didn't hear for many years anything promising (for sure not for ffmpeg). CUDA filters are something else.
    Last edited by pandy; 16th Mar 2022 at 14:44.
    Quote Quote  
  6. I also brought up this problem on the Intel Community forum.

    After some back-and-forth, Intel decided that since my CPU isn't the "latest and greatest", there is no support for it and won't look into the problem.

    That's not exactly the way they put it, but they did say the CPU isn't supported anymore.

    This is like saying "your car is more than 5 years old, so we won't sell you oil and air filters for it anymore, and if it catches on fire it's your problem"

    So we can't expect any help from Intel unless one of you has a computer with a CPU in current production and can reproduce the problem. I expect that many of you do have newer computers, and will expect to go to ffmpeg 5.0, so hopefully we can find out if the fault really is in my older CPU or if it's in the way ffmpeg is built.

    If any of you can reproduce this you might want to go to

    https://community.intel.com/t5/Graphics/ffmpeg-5-0-breaks-QSV-syntax-for-hardware-acec...368941#M106365
    Quote Quote  
  7. Typical for large corpo such as Intel - IMHO you should try to raise issue on ffmpeg forum - perhaps bug tracker https://trac.ffmpeg.org/wiki/WikiStart ?
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!