[FFmpeg-devel] [PATCH] doc/examples/encode_video: add qsv encoder support

Mark Thompson sw at jkqxz.net
Wed Aug 2 20:17:43 EEST 2017

On 02/08/17 07:28, Nicolas George wrote:
> L'octidi 8 thermidor, an CCXXV, Li, Zhong a écrit :
>> It is similar to hw_device_match_type_in_name() in ffmpeg_hw.c:
>> 	if (strstr(codec_name, type_name))
>>        return type;
> I must say, I really do not like the idea of having an API example
> making that terrible construct official.
> If testing the hw device type is really absolutely necessary in the API,
> then we need some kind of avcodec_get_hw_type() function to do that
> cleanly, before considering the API usable and documenting it.
> Testing the codec name in external code is a big no, testing part of it
> for a three-letter substring even more so.

Yes.  The current API behaviour all assumes that the user knows what sort of device they want to supply for a given named codec.  The use in ffmpeg is a temporary hack to avoid breaking existing devices while we decide how to express this properly in avcodec.

A full solution would be something like adding a new public field to AVCodec with an array of possible device types and corresponding hardware pixfmts.  The user can then supply a device of one of those types as AVCodecContext.hw_device_ctx, and see the matching pixfmt later in get_format() if it is supported.  The qsv codecs would have AV_HWDEVICE_TYPE_QSV / AV_PIX_FMT_QSV in this field, hwaccelerable codecs could have multiple depending on the build configuration.  (This is also solving the related problem that there isn't currently any way to know the matching pixfmt for a device type on a codec, hence for example the table in the hw_decode example.)

I'll get around to finishing this off at some point in the not-too-distant future.

- Mark

More information about the ffmpeg-devel mailing list