[FFmpeg-devel] [PATCH][7/8] Add VA API accelerated H.264 decoding (take 4)
Thu Feb 12 01:05:19 CET 2009
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
>> 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
>> codec and hwaccel_id set beforehand, if acceleration is requested.
> 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
> 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.
More information about the ffmpeg-devel