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

[Gwenole Beauchesne]

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
>>> removed.
>>> 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.