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

Michael Niedermayer michaelni
Sat Feb 21 00:58:23 CET 2009


On Sat, Feb 21, 2009 at 12:48:40AM +0100, Gwenole Beauchesne wrote:
> Le 21 f?vr. 09 ? 00:27, Michael Niedermayer a ?crit :
> 
> >>> avctx->pix_fmt = ff_query_pixfmt(avctx, avctx->codec->id);
> [...]
> >> your intent is a generic function for all codecs, that sounds
> >> overkill right now, IMO. What would be the default value for AVCodecs
> >> not implementing pix_fmts[]?
> >
> > it wont be called for such codecs
> 
> ok, so we can still have preliminary checks for other codec_id or  
> codec flags and only replace the YUV420P cases?
> 
> e.g. keep the current SVQ3 test as is and then have only have the  
> ff_query_hwaccel_codec() replaced by your two lines?

yes iam really just asking for ff_query_hwaccel_codec to be split not
any large change ...


> 
> And, to be clearer, have the ff_query_pixfmt() pass hw pixfmts first,  
> then AVCodec::pix_fmts[] or YUV420P if NULL?

yes that sounds correct


> 
> >> (ii) what is codec id needed for?
> >
> > 2 codecs might use the same hw pixfmt but different hwaccels, maybe
> > this is unlikely and i dont mind codec_id being droped considering  
> > this
> > is just a internal function
> 
> well, our current practise is to have hw pixfmt + CODEC in the name.  
> People should stick to that and I doubt hooks would be implemented in  
> the same way anyway.

iam just thinking that the ideal hw pix_fmt would not depend on the codec
i mean the pix_fmt specifies what data there is in the "picture" and that
is some values taken from the headers + the undecoded slices / frame
the structs used for this dont have to differ between codecs, especially
not between h263/mpeg1/2/4, these are similar enough so a single one
should be able to handle all. Surely with a few unused fields here and
there but no totally different pix_fmt ...


> 
> Anyway, for me, a bijection is from one element to another one, not  
> through a third-party helper. ;-) I mean, having an a2b function but  
> using a c looks weird to me, including the name.

if its a true bijection then one would be redundant and should be removed
:)


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090221/b61775a7/attachment.pgp>



More information about the ffmpeg-devel mailing list