[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 7.1)
Tue Feb 24 18:52:33 CET 2009
On Tue, Feb 24, 2009 at 06:08:47PM +0100, Reimar D?ffinger wrote:
> On Tue, Feb 24, 2009 at 04:58:30PM +0100, Michael Niedermayer wrote:
> > On Tue, Feb 24, 2009 at 04:24:36PM +0100, Gwenole Beauchesne wrote:
> > > On Tue, 24 Feb 2009, Michael Niedermayer wrote:
> > > > 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
> While in MPlayer's current design a per-codec PIX_FMT is not necessary,
> I do not think the situation is comparable to the per-level PIX_FMT
> The notable differences are
> 1) levels/profile changing within a file is supported in the software
> implementation (and such files might be even valid), I do not like a
> design that would restrict the hardware implementation to be
> _necessarily_ less powerful.
changing pix_fmt in the middle of a file is not impossible ...
> Not using per-codec PIX_FMTs seems more likely to me to just complicate
> things, though I do not know for sure.
well i have no strong oppinion on this but i dislike the
half page of code per API X codec X variant (IDCT/MC/VLC)
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel