[MPlayer-dev-eng] [PATCH] Add video acceleration infrastructure

Uoti Urpala uoti.urpala at pp1.inet.fi
Mon Sep 28 23:29:19 CEST 2009


On Mon, 2009-09-28 at 17:08 -0400, compn wrote:
> On Mon, 28 Sep 2009 21:36:07 +0300, Uoti Urpala wrote:
> >> What disadvantages for instance?
> >
> >Reliability (decoding differences and different bugs compared to SW
> >decoding,
> 
> this is true with any decoder (ffmpeg) and infinite samples. i think in
> this case, we switch mis-aligned stack and gcc miscompilations for bugs
> in the driver.

Why do you keep posting in technical threads whose subject matter you
know little about? Some days ago you posted in the overlay thread, now
this. You're just adding noise.

> > things like VDPAU display preemption),
> 
> its still faster?

It's not necessarily faster, and this was about reliability anyway.

> > reserved resources (video RAM limits,
> 
> all vo have this problem, xv has badalloc and max overlay size etc

The alternative here is software _decoding_ which has no such problems.


> > limits on simultaneously existing hardware decoder instances).
> 
> again, this is a limit with all vo.

Again, we're talking about decoding (and in this case your comment makes
even less sense).


> mplayer is currently set by default to use mpegpes for mpeg1/2 because
> it is faster. is there a difference between vdpau/vaapi and mpegpes ?

The only relevant question about mpegpes is why is it still enabled and
spewing irrelevant error messages whenever you play an mpeg file. And I
guess the answer is that nobody has cared enough to fix things.




More information about the MPlayer-dev-eng mailing list