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

[Michael Niedermayer]

On Tue, Feb 24, 2009 at 04:24:36PM +0100, Gwenole Beauchesne wrote:
> 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.

id like a new and clean AVhwaccel API that is not restrained by past design
decissions.


> 
> What excuse would you find next? Were you on drugs when you accepted the 
> earlier patches?

VDPAU did not add multiple near identical lists for get_format(), the problem
didnt exist before so required no solution before ...


> Were you paid somehow? 

no, sadly not


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

its because you are spending more time making attempts at insulting me instead
of coding.
But rest assured i appreciate your friendly way of communicating.


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

comments from reimar as well as comments from you about improving the design
and implementation are welcome

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- 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/20090224/ee482d18/attachment.pgp>