[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 7.1)
Tue Feb 24 19:01:43 CET 2009
On Tue, Feb 24, 2009 at 06:52:33PM +0100, Michael Niedermayer wrote:
> 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
> > case.
> > 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 ...
It is a bit problematic conceptually though, and does it actually work
or would most libavc users probably handle it in a highly exploitable
> > 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)
I just wanted to express my suspicion that this, contrary to the other
case, might just move that half page of code to whoever uses lavc :-)
If there wasn't the issue of public API it's the typical case where I'd
suggest to get it in one way and then see if it can and should be
More information about the ffmpeg-devel