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

[Uoti Urpala]

On Mon, 2009-09-28 at 20:00 +0200, Gwenole Beauchesne wrote:
> Le 28 sept. 09 à 18:22, Uoti Urpala a écrit :
> > At least on a desktop machine the disadvantages are likely to be much
> > more significant.
> 
> What disadvantages for instance?

Reliability (decoding differences and different bugs compared to SW
decoding, things like VDPAU display preemption), reserved resources
(video RAM limits, limits on simultaneously existing hardware decoder
instances).


> >>> Is there currently any case where using VAAPI decoding would be the
> >>> preferred choice in practice?
> >>
> >> I would say the preferred choice is whatever is available and used by
> >> FFmpeg.
> >
> > I meant my question in more practical terms. Is there currently any  
> > case
> > where users would get some real and significant practical benefit from
> > using the functionality added by your patches as opposed to some
> > previously existing decoding method?
> 
> Users? Probably not. Developers, yes. Hey, wasn't you that wanted to  
> avoid code duplication in VOs?

I don't remember a discussion about code duplication that you could be
referring to here. Anyway I don't see how such could be applicable. How
would adding extra code reduce duplication? As far as I can see these
patches in no way allow removing any existing code duplication.

I hope you're not still thinking about using VDPAU through this API?
That you ever thought that was a practical idea shows you're not
familiar enough with the issues. You probably shouldn't try to write a
grand unified architecture for everything acceleration-related if you
don't know what would be required of it in practice.

What developer benefits are you referring to above? Adding more code
like these patches certainly wouldn't make the codebase any nicer to
work with. So does your reference to "duplication" mean you think the
developer benefit would be the ability to delete other code later? I'm
pretty sure you'd be wrong if so - maybe you could replace parts of XvMC
but that can be mostly ignored now so replacing it would be of little
benefit. Or are you talking about helping some future VAAPI development
or such you'd like to do?