[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 7.1)
Tue Feb 24 16:24:36 CET 2009
On Tue, 24 Feb 2009, Michael Niedermayer wrote:
> On Tue, Feb 24, 2009 at 03:56:55PM +0100, Gwenole Beauchesne wrote:
>> On Tue, 24 Feb 2009, Michael Niedermayer wrote:
>>>>> Now, your suggested approach requires as many lists as (HW accelerators) x
>>>>> (chroma formats) x (sub-codecs).
>>>> You dont need to split pix_fmts per codec, its done currently and iam not
>>>> asking you to change it but i would be happy if you did change it :)
>>> after seeing your patch, i think per codec pix_fmts really should be
>>> This would make the code much simpler and cleaner. It also would greatly
>>> simplify get_format() for user apps,having to test just for one pix_fmt
>>> er hwaccel API instead of for one per codec X API
>> Not really. The user app then would have to check avctx->codec->id itself
>> as not all accelerators would implement the same codec...
> and not all accelerators implement all profiles, we already insistent on
> removing profiles from the pix_fmts, i dont see why codecs should be
> handled differently.
You obviously did since you accepted the initial VDPAU patch... Really,
this is not going to anywhere, it's far beyond "factorization" already.
It's an "overhaul" of the existing code.
What excuse would you find next? Were you on drugs when you accepted the
earlier patches? Were you paid somehow? Please clearly tell why does it
take so much time to accept so much simpler patches than the initial VDPAU
work? There must be a reason, but I don't get it. Ah, probably too narrow
lookahead buffer, but that would also be surprising.
> the user app can use whatever it needs from AVCodecContext to decide if
> its accelerator can handle it or not ...
Then you also nicely break Reimar's recent map tables work since you no
longer have any bijection there. And requiring an extra arg (for e.g.
codec_id) is not a really clean approach either.
More information about the ffmpeg-devel