[FFmpeg-devel] [PATCH 00/24] Generic hardware device setup and miscellaneous related merges

[Mark Thompson]

This merges a set of stuff from libav to do with hardware codecs/processing.

The two most interesting features of this are:

* Generic hardware device setup.  This finishes the uniform structure for hardware device setup which has been in progress for a while, finally deleting several of the ffmpeg_X.c hardware specific files.  Initially this is working for VAAPI and VDPAU, with partial support for QSV.  A following series by wm4 (start from <https://git.libav.org/?p=libav.git;a=commit;h=fff90422d181744cd75dbf011687ee7095f02875>) will add DXVA2/D3D11 support as well.

* Mapping between hardware APIs.  Initially this supports VAAPI/DXVA2 and QSV, OpenCL integration with those is to follow.  The main use of this at the moment to to allow use of the lavc decoder via a platform hwaccel and hence avoid the nastiness of the specific  *_qsv decoders (for example: "./ffmpeg_g -y -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4 -an -vf 'hwmap=derive_device=qsv,format=qsv' -c:v h264_qsv -b 5M -maxrate 5M -look_ahead 0 out.mp4", and similarly with DXVA2).

Other oddments:
* Support for the VAAPI driver which wraps VDPAU.
* Field rate output for the VAAPI deinterlacer.
* hw_device_ctx support for QSV codecs using software frames (fixes some current silly failure cases when using multiple independent instances together).
* Profile mismatch option for hwaccels (primarily to allow hardware decoding of H.264 constrained baseline profile streams which erroneously fail to set constraint_set1_flag).
* Documentation for the hardware frame movement filters (hwupload, hwdownload, hwmap).

VP9 VAAPI encode support would be here, but is not included because it depends on the vp9_raw_reorder BSF, which is only written with the bitstream API rather than with get_bits.  I know that was skipped earlier, but has there been any more discussion on merging that?  Would it be easiest to just convert the BSF?

Thanks,

- Mark