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

[Bart Z Lederman]

I used ffmpeg -help to extract the information for the libx264, h264_amd (AMD), h264_nvec (Nvidia), and H264_qsv (Intel) encoders.  I've combined the information into a spreadsheet (csv and LibreOffice ods) file.  I believe this makes it easier to compare the various encoder options.

What would be the best way to make this available to everyone?

[Bart Z Lederman]

I apologize for not being here for a while, it's a lot longer than I realized. I've been doing a lot with hardware accelerated encoding and filtering, and I've been trying to obtain more information on this subject in other forums (and receiving mostly abuse for my efforts).

I know now quite a bit more on the subject and would like to share it.

First, and possibly most important: if you can only support one architecture it should be Intel Quick Sync (QSV) for several reasons.

First: there are literally millions of computers in use today that have QSV, though many people don't know it.  It's built in to the processor, you don't have to buy anything extra.  This also includes "low power" processors built into laptops (I found out I have one such system).  To use Nvidia / CUDA or AMD you need to have add a graphics card; not all of them support hardware acceleration, and you can't upgrade all systems because there might not be enough power, or enough slots. And if you have a laptop you may not be able to upgrade at all.

Next, there are many more filter options available for Intel / QSV than for Nvidia / Cuda.  The vpp_qsv filter alone can do a lot of processing that would take multiple filters otherwise, and it will do things no Cuda filter can do.  In addition, for what the accelerated filters can't do you have to use the "standard" filters. Mixing Intel and "standard" filters requires no effort at all, you just use whatever filters you want.  Mixing "standard" and Cuda filters is very far from obvious, and you have to specify uploading every frame to the hardware, use the Cuda filter, download every frame back, and then use a "standard" filter or filters.  Once you know the secret magic formula to do this it will work, but there is extra overhead for uploading and downloading frames. I've also found the information from Nvidia to be very poor, often misleading, and sometimes wrong.  I've had to search and experiment to get things to work at all, and the Nvidia "support" forum was no help.

I did get a little bit of support form Intel (after a long discussion), and I have relatively complete information on the vpp_qsv filter.

Tests I've done show that doing decoding and encoding makes the process go very much faster than the default CPU processing.  I've seen speed-ups as great as 30 times faster, and speed-ups of 5 to 20 times are common. Plus, with the work being done by the GPU the CPU is freed up to do other work.  Using the hardware accelerated filter doesn't add a lot of speed, but it does reduce the CPU load.

Switching over to QSV is now quite simple know that I know how it's done, and I will be happy to share everything I know with everyone.  Just let me know where you want to see it.

Right now I'm using Avidemux mostly as a way to find the cut points, size of cropping, etc., so I can set up ffmpeg commands to do the actual work.  The speed advantage really is amazing.  I want to do everything I can here to help other people speed up their video processing after spending a month with people in other forums saying I'm unreasonable for asking where to find documentation on QSV and Cuda.

[eumagga0x2a]

On Linux, we use QSV accelerated encoding for H.264 and HEVC via FFmpeg + libva (and also directly, but for H.264 and with very limited configuration only). Zero hassle. libva offers also a few filters, but currently only resizer and deinterlacer are implemented (I think it is all my hardware is able to do).

For Windows, it would be necessary to find a way to cross-compile shared FFmpeg libs with QSV support.

Due to architectural limitations, we always have to download and re-upload decoded pictures to the GPU which severely limits performance compared to FFmpeg which is able to pass hardware surfaces from decoder through filters to hw accelerated encoder seamlessly.

[Bart Z Lederman]

I'm a little surprised you're finding issues with QSV on Linux with ffmpeg.  I will have to do some more testing there.

There are at least two people who are building ffmpeg with QSV (and Nvidia and AMD) support for the Windows version which is available from the ffmpeg.org web site.  I've never had to build my own version to get QSV support.  Again, I will have to do more testing on Linux, but the version I installed through the normal Linux install procedure pulled a version of ffmpeg with QSV already built in from the repository.  My quick tests so far indicate that the decoder and encoder work the same as on Windows, with the same command line.

My understanding from previous messages in this forum is that Avidemux passes commands to ffmpeg, which does the work; so I would think that getting it to take advantage of QSV would not take much effort.  The biggest bonus is in having the codec decode and encode the video, and I have found that to be quite easy. It involves some fixed text on the command line, and restricting some of the options: for example, the QSV encoder does not have an "ultrafast" preset, but does have "superfast" through "very slow". (And changing -crf to -q:v .)

Uploading and downloading to the GPU has never been needed for any of my QSV and Nvidia tests for hardware accelerated decoding or encoding.  This has only been needed when using an enhanced filter, and only for Nvidia: and using enhanced filters is a secondary benefit that can be deferred, or not done at all. 

[eumagga0x2a]

I'm a little surprised you're finding issues with QSV on Linux with ffmpeg.

The issues are with us, not with ffmpeg (at least not the issues). For optimal performance when no filtering by other means than VA-API is involved, hardware surfaces holding decoded pictures need to be passed between hw decoder and hw encoder. We cannot do this at the current stage.

On Windows, the only currently available in Avidemux hw acceleration interface for video decoding is DXVA2, well aged, which can't exchange hw surfaces even between decoder and video display.

My understanding from previous messages in this forum is that Avidemux passes commands to ffmpeg

No, this is wrong. We don't use ffmpeg command-line utility, we use some of the libraries, patched and configured to our needs.

[spiceagent11]

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?
https://vidmateapp.win | Bluestacks 3 | moviesrush

[eumagga0x2a]

Perhaps I'm missing something "obvious", but could someone point me to instructions on how to do this?

For now, in order to be able to use hardware H.264 and HEVC encoders on Intel, the instructions are as simple as installing Linux and using a Linux build of Avidemux (if it needs to be an official appImage, then please the one from the "appImage4Buster" directory of the nightly server).

There hasn't been any progress on Windows yet, i.e. on Windows, Avidemux offers hardware-accelerated encoders only for users of recent NVIDIA graphics cards.

[butterw]

12th gen Intel processors (and high-end 11th gen) feature igpus (ex: uhd 730) with a very good hardware encoder for h265 + also an av1 hw-decoder.

Hopefully Avidemux can make use of qsv at some point on Windows.

Hardware encoders are likely the future for codecs more complex than h264, at least for most users.

[butterw]

Any update on the state of qsv support in Avidemux ?

I have Intel i3-12100.

I'm currently using x265-slow CRF=25 (on Win10) to encode, but will looking into h265 hardware encoding in the future.

The standalone encoder tools tend to use qsvenc by rigaya rather than ffmpeg from what I've seen. Possibly because it allows the more advanced options to achieve best quality or maybe because it is easier to configure, I don't know.

[eumagga0x2a]

Unfortunately no progress, not even started. Didn't have time and physical resources for coding at all for quite a long period of time while problems in Avidemux kept piling up due to changes in FFmpeg and in Qt.