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

Gwenole Beauchesne gbeauchesne
Tue Feb 24 06:26:51 CET 2009


Le 24 f?vr. 09 ? 02:25, Michael Niedermayer a ?crit :

>>>> Please also point me to the patch that replaces the VDPAU  
>>>> PIX_FMTs, I
>>>
>>> what should that patch replace them with?
>>
>> I don't know, you said "you can't register new pixel formats" and I
>> interpreted that as "you can't add new pixel formats", i.e. no HW
>> formats in pixfmt.h. Hence the confusion.
>
> i meant
> you cannot create new pixel formats _at runtime_
> PIX_FMT_NB prevents it ...

I agree with you but please read the patch again, there is no new  
pixel formats created at run-time.

>>>> have just svn update'd the tree and I probably missed it or someone
>>>> forgot to commit that bit.
>>>>
>>>> How is all this supposed to work now, specifically?
>>>
>>> This is very simple and really isnt "now" ...
>>> each AVCodec has a constant list of pix_fmts, these get passed to
>>> get_format()
>>> the user app through its get_format() chooses one of them and
>>> returns it
>>> the codec looks up the matching AVHWAccel.
>>
>> Your precondition is not met: the list of pix_fmts is not constant  
>> for
>> some AVCodecs. see e.g. mpeg12.c, the pix_fmt depends on
>> chroma_format.
>
> i need more sleep, i have forgotten about that, still my point stands
> that your page of code is not needed
> 3 static const lists for mpeg12 will do

"page of code", well, you will see that the patch is as long as  
before. ;-) You save a few bytes though.

However, I would like to point out that the current approach has the  
benefinit for defining the availability of the new accelerator only  
once. e.g. a single  REGISTER_HWACCEL (MPEG2_VAAPI, mpeg2_vaapi); in  
allcodecs.c and you are done. Now, you will have to mention that  
elsewhere (in a pixfmt_fmt_mpeg2_420[]). Somewhat a one-definition- 
rule man.

OK, now I take this coding rule: "no matter how the code is obfuscated  
(for the dev), as long as it's compact and faster by a very marginal  
number of cycles (for the user), it  should be OK". I will keep this  
in mind next time.



More information about the ffmpeg-devel mailing list