encoding with intel h264 (HW), any plans for more configuration options ?

[thomas.rehberg]

I´m running version 2.7.4 Linux 64bit, and I have a Haswell platform running. When using the intel H264 encoder (which is the ffmpeg vaapi HW encoder) I can open a config dialog, however, very limited options only.
No rate control, lookahead, etc. that one can select here. Disappointing, as my platform is compatible to use the Intel HW encoding (and yes I know it´s not of the same quality as SW encoding, but very fast and CPU friendly).
Are there any plans to add the options that are available just as you would encode at the terminal ?

I would volunteer to play the testbench, but I´m afraid I cannot change the code...

[eumagga0x2a]

Enhancing the FFmpeg VAAPI video encoder plugin is definitely on my wish list, but not a priority.

I would volunteer to play the testbench

Thanks, I have a testbench sitting on the desk 30 cm away from the keyboard I'm typing on, so this is not a problem.

but I´m afraid I cannot change the code...

This was exactly how I thought about Avidemux three years ago, starting with zero coding knowledge.

[thomas.rehberg]

ok, so then nothing that I can expect near term.
Could you easily indicate where in the code the gui popup of the codec configuration is located ?

[eumagga0x2a]

It is in ffVAEncConfigure() located at avidemux_plugins/ADM_videoEncoder/ffVaH264/ADM_ffVAEncH264.cpp:346.

You will need to extend the ffvaenc_encoder struct in avidemux_plugins/ADM_videoEncoder/ffVaH264/ffVAEnc_H264.conf and regenerate the .h and the _desc.cpp files by running

Code Select Expand

../../../cmake/admSerialization.py ffVAEnc_H264.conf

in the ffVaH264 directory. New functionality will probably go into ADM_ffVAEncH264Encoder::configureContext().

For multipass encoding, you might want to look at the implementation in ADM_ffMpeg4.cpp.

[Bart Z Lederman]

I'm a bit confused here.

I see references to various hardware acceleration options and improvements being made to Avidemux, but I don't see any instructions on how to actually access them.

I've done some tests using ffmpeg and the h264_qsv (Intel) codec, and it makes a huge improvement in the time it takes to encode a video (12x or more).  I'd like to use that
with Avidemux, but can't figure out how.  And I also have a system with an Nvidia card
and would like to use the nvenc_h264 codec if possible.

Perhaps I'm missing something "obvious", but could someone point me to instructions on how to do this?  Or perhaps elaborate on the recent news about hardware acceleration enhancements to Avidemux?

Thanks.

[eumagga0x2a]

Which version of Avidemux (it should be the latest git or as close to it as possible) on which operating system are you using? LibVA-based hw acceleration is Linux-only.

[Bart Z Lederman]

I'm using 2.7.6.20187 VC++ 64 bits, Windows 7 Professional 64 bits.  I missed the part about Linux only, I do have a Linux laptop but it's much slower.

Is there support for Nvidia at all?  My secondary PC is Windows 7 64 bits and has an Nvidia 8400 card: but I have not been able to get ffmpeg to use CUDA or Nvidia codecs.  I get an error message, but when I look it up I see nothing helpful.

Any suggestions would be welcome.

[eumagga0x2a]

Is there support for Nvidia at all?

Yes, there is, a quite good one if you use a nightly. However...

My secondary PC [...] has an Nvidia 8400 card

...this one doesn't have any encoding support (it may provide decoding support for some codecs including H.264 via VDPAU on Linux). Additionally, very recent NVIDIA drivers are needed for NVENC encoder plugins in Avidemux to work, so that old cards which require legacy driver versions most probably won't help. You need a graphics card starting with the Kepler generation (but please make sure you don't get one with a GK108, GM108 or A100 GPU – those don't have an encoder either).

GTX 1050 might be a balanced choice, albeit really interesting features like AV1 support are not available prior to RTX 30xx (it doesn't matter for Avidemux right now, but may be very relevant in near future).

[Bart Z Lederman]

I've been doing more research.

The one system I have that has the right Intel processor is working well, though the codec is a bit limited in what options it has (compared to Nvidia and AMD).  In this case, it's the actual processor that determines if it has hardware video encoding.  Intel has a list of which processors do this.

https://www.intel.com/content/www/us/en/support/products/81503/graphics/graphics-for-previous-generation-intel-processors/intel-hd-graphics-for-previous-generation-intel-processors.html

Be advised that this web page doesn't work with all browsers, but if it works it lets you search on "Intel Quick Sync Video" (and other qualifiers).

Nvidia also has a web page that lists the base cards that support video encoding:

https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new#Encoder

I'm using this to look for cards that should work in my system.  However, from what I've seen so far, I could buy an entire refurbished PC with Intel core i5 or i7 processor for less than what many Nvidia cards cost!  The only problem is that I'd really like to remain on Windows 7 rather than 10.  (I'm also researching for a friend, he has a tower PC so there are more cards that will work for him, but he really had problems working with Windows 10 on his previous laptops and slates.)

AMD is a write-off.  They don't have any usable information on their web site.  I got a reply from them that says that they just supply the chip sets to other manufacturers, if you want to know if a card does hardware encoding you have to find out who makes the card and ask them. But they don't even say which chip sets actually support hardware encoding.  It's very unfortunate, because I used AMD some time ago on my Macintosh systems, and they have a good reputation, and the AMD codec seems to have as many options as Nvidia: but finding out what card does what is going to be very difficult.

So now it comes down to this: which vendor's hardware encoding is going to get the best support from Avidemux (and other programs).  Handbrake does all three, but it's really not a video editing program.  So if Avidemux has plans to support Nvidia (or Intel or AMD) then that would be my first choice for a graphics card.

As for the driver, that doesn't appear to be as much of a problem.  All three offer 'legacy' drivers.  For Intel, it's built into the processor, so my relatively old PC handles the Intel video codec (h264_qsv) with no problems at all.  The other vendors say they have updated drivers and graphics software for old boards, so it appears that it all depends on the boards / chip sets and the codec.  If h264_amf or h264_nvec works now, it should work on any of the capable boards.  (Of course, someone would have to try it to see if what the vendors say is true ;-)

I hope this helps with figuring out what sort of hardware support is feasible.

[Bart Z Lederman]

I spoke just a little too soon.

I've received a second answer from AMD.

https://www.amd.com/en/products/specifications/graphics

is a selector for their cards.  Way off to the right you can select for various video formats decoding and encoding.  This makes it relatively easy to find cards that will work (I think).

So the question still remains, what hardware will be supported by the hardware?

Thanks for taking the time to look through all of this.

[eumagga0x2a]

So the question still remains, what hardware will be supported by the hardware?

I'm unsure you really meant "hardware" and not "software". Regarding HW accelerated video encoding on Windows with Avidemux right now, I think that I've already answered the question in full: NVIDIA only and only with very recent drivers. Speculating about the future is futile.

[Bart Z Lederman]

Yes, I got that mixed up.  Your interpretation was correct.

The more I look at this, the more arguments that can be made in favor of Nvidia being the hardware to support, at least as a first choice.  One might argue that more people will have Intel as it's built into the processor; but looking at what filters and codecs support Nvidia vs. QSV, Nvidia wins.  There are CUDA aware versions of Yadif and other filters, but not for QSV or AMD.  There are fewer encoding options that can be used for the QSV hardware than for Nvidia, if ffmpeg is anything to go by.

I found a refurbished Nvidia card on Amazon at a less-than-exorbitant price.  It's on the Nvidia supported list, so I took a chance and ordered one.  Since I chose free shipping it will be a while before I get it; at least a week.  I will report back when I have results.

[eumagga0x2a]

There are fewer encoding options that can be used for the QSV hardware than for Nvidia, if ffmpeg is anything to go by.

Avidemux is just a shell around FFmpeg with regard to HW accelerated encoding via NVENC. I don't think that it will be any different for QSV if QSV turns out to be viable.

[Bart Z Lederman]

There are fewer encoding options that can be used for the QSV hardware than for Nvidia, if ffmpeg is anything to go by.

Avidemux is just a shell around FFmpeg with regard to HW accelerated encoding via NVENC. I don't think that it will be any different for QSV if QSV turns out to be viable.

I was entering a reply and must have accidentally pressed a function key or something.  I will try again.

Most of the commands that need to be passed to h264_qsv are the same as for libx264.  There aren't as many options, but I think the average user isn't going to use many of the options in libx264.  The work to call h264_qsv can probably be shared with h264_nvidia and h264_amf.

Information about h264_qsv is scattered about, but I've collected enough to switch over what I've been doing directly in ffmpeg to use QSV, and will be quite happy to share all of it.

For as simple example, I have a TV recording box that records off-the-air broadcast tv and puts it into MTS format, which can't be played by all devices.  If the broadcast signal is less than perfect then there are defects in the recording that need to be fixed.  So I run them through ffmpeg which will fix most of the problems, and then I can view them.  I might also run them through Avidmux to edit them.

The basic command to do this is:

ffmpeg -i "input.mts" -c:a aac -b:a 128k -ar 48000  ^
-preset veryfast -profile:v high -level 4.1  ^
-vf "yadif=0:0:0" -crf 20 "output.mp4"

To use QSV acceleration:

ffmpeg -i "input.mts"  -c:a aac -b:a 128k -ar 44100 ^
-c:v h264_qsv -preset veryslow -profile:v high -bsf:v h264_metadata=level=41 ^
-vf "yadif=0:0:0" -q:v 20 "output.mp4"

The only changes are -q:v instead of -crf and removing the decimal point for the level.

I've also found that in most cases I can leave the choice of quality and level to the codec to decide: it's only when I want to watch the video on a Blu-Ray player using a drive in the USB port that I have to limit the level to 4.1.

I will write up a complete list of everything I've found so far about switching to QSV and post it, hopefully later today (my time) so that others won't have to search the internet to get the bits and pieces.

Supporting h264_nvec and h264_amf look like they will be a little easier because they support more options than qsv.  But, as I said, I've found you can leave most choices on what to do to the codec and a lot of options aren't needed.

[Bart Z Lederman]

There are a number of options that differ between the various encoders.  Some I would classify as being rather "esoteric".  Most users probably won't ever use them (if my experience is anything to go by).

These are the ones I think are significant.

-preset

libx264 goes from ultrafast to placebo
h264_qsv goes from veryfast to veryslow
h264_nvenc goes from fast to slow plus a variety of other settings like hp, lossless,
          low latency, etc.

-profile

libx264, QSV and NVENC have baseline main high
h264_nvec also has high444
h264_amf has main high constrained_baseline constrained_high
libx264 can be modified with --tune . I don't see this in the other codecs.

-crf

I only see this in libx264.  The other codecs apparently need -quality or -q:v

In my tests so far, for the most part letting h264_qsv choose the quality
and bitrate has been working well. 

As I mentioned before, letting it chose the profile and level based on the size
and nature of the video also works well unless you need to constrain the limit
to run on a particular device.

These are the qualifiers listed for the encoders.  I've run into some 'higher level'
qualifiers that seem to be handled differently between codecs. libx264 seems to
hide it's qualifiers in a separate document.  Common qualifiers like -b -minrate
and -maxrate appear to work the same in libx264 and h264_qsv (though frankly,
I don't think they work very well in either library).

Filters like yadif, crop, -ss, scale, etc. are independent of the encoder, though
there are some filters like yadif that also come in a hardware-aware version.

Perhaps the best way to proceed is for you folks to tell me what qualifiers are
important and I'll test them for QSV.  In a week or so I'll also be able to test
Nvidia (I hope).