[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 7.1)

[Gwenole Beauchesne]

On Tue, 24 Feb 2009, Michael Niedermayer wrote:

>> So, it won't be enough to simply fill in pix_fmts for
>> all mpeg*_decoder with e.g. {PIX_FMT_VAAPI_MPEG2, PIX_FMT_VDPAU_MPEG2,
>> PIX_FMT_YUV420P}. Besides, for someone that doesn't like duplicate
>> code, you seem to accept duplicate data very easily. ;-)
>
> i suspect the 3 static const lists need less space than your function

Not that much. You'd need several lists.

- ff_query_pixfmt() is 192 bytes ;
- ff_query_pixfmt(avctx, avctx->codec->id) is 21 bytes ;
- avctx->get_format(avctx, pixfmt_mpeg2_420) is 17 bytes

You only need at most N ff_query_pixfmt() calls, where N is the number of 
codecs we deal with. So, the current approach is around 276 bytes and 
independant on the number of HW accelerators.

Now, your suggested approach requires as many lists as (HW accelerators) x 
(chroma formats) x (sub-codecs).

Let's examine a realistic set of HW accelerators at VLD level:
- DXVA: MPEG-2, MPEG-4, H.263, H.264, WMV3, VC-1 and probably others
- VA API: MPEG-2, MPEG-4, H.263, H.264, WMV3, VC-1
- VDPAU: MPEG-1, MPEG-2, H.264, WMV3, VC-1

We have the following sub-codecs:
- mpeg12.c: MPEG-1, MPEG-2
- h263dec.c: H.263, MPEG-4 (I don't want to count MSMPEG-4 variants, I 
said "realistic" ;-))
- h264.c: H.264 only
- vc1.c: WMV3, VC-1

Assumptions:
- enum PixelFormat is typically 4 bytes long
- HW accelerators only support 4:2:0 chroma format in practise (though 
they theoritically can handle up to 4:4:4)

We need:
- h263dec.c: 2 pixfmts list of 4 elements each
- h264.c: 1 pixfmt list of 5 elements
- mpeg12.c: 2 pixfmts list of 5 and 3 elements
- vc1.c: 2 pixfmts list of 5 elements each
that's 124 bytes for the pixfmt lists and 4x 17 bytes for the 
::get_format() calls for that

i.e. 200 bytes, not counting the extra conditional code for sub-codecs. 
Compare that to the initial 276 bytes, it's not a that large gain. Now, 
add even more accelerators and you'd get equivalent sizes.

Sure, you can tell me there are means to compile with 1-byte long enums 
but hey, I meant the common and usual case. ;-)