[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 7.1)
Tue Feb 24 16:58:30 CET 2009
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
> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel