[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 7.1)
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
>>> 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
>> some AVCodecs. see e.g. mpeg12.c, the pix_fmt depends on
> 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-
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