[FFmpeg-devel] [PATCH][7/8] Add VA API accelerated H.264 decoding (take 4)

[Gwenole Beauchesne]

Le 11 f?vr. 09 ? 21:51, Michael Niedermayer a ?crit :

>> However, an alternative is to have an AVHWAccel with init(), uninit()
>> member functions, that's the accelerator class + an AVHWAccelCodec  
>> which
>> is more consistent with existing AVCodec and that would have the
>> start_frame(), start_slice() et al. instead.
>
> whats the point of the extra complexity?

e.g. a means to initialize display-independent (and player- 
independent, implementation-wise) accelerators and cleanly  
deinitialize accelerator (lazy-allocated) data. Haven't you noticed  
that the current VDPAU implementation is memleaking bitstream buffers?  
I think if FFmpeg allocated data it should release it itself somehow  
when it's not longer needed, users of the lib will generally forget  
about it otherwise.

BTW, the purpose of the hwaccel_id was also to replace the  
xvmc_acceleration too. Though it's probably better to keep it alive  
alone.

>> codec and hwaccel_id set beforehand, if acceleration is requested.  
>> That
>
> no
>
> once the codec has determined all needed stuff mpeg1 vs mpeg2 video  
> res, ...
> it will querry registered AVHWAccels to see which could decode it and
> then present a list via the AVCodecContext.get_format() callback to  
> the
> user app. The user app then just returns the pix_fmt it wants and that
> implicates a AVHWAccel or none.

That could work though each codec will have to look up the  
AVHWAccelCodec itself and amend it to the avctx. i.e. have an  
ff_get_hwaccel_pix_fmts() function called by each codec? Since that  
constructed list needs to be dynamic (basically copying each  
pix_fmts[] for each AVHWAccelCodec implementing said codec id -> e.g.  
PIX_FMT_VAAPI_MPEG2, PIX_FMT_VDPAU_MPEG2, PIX_FMT_NONE), this means  
extra memory management and error recovery in the callee. This is only  
4 codecs, so we probably can tolerate this kind of low duplication.