[MPlayer-dev-eng] vdpau codec priority?

[Uoti Urpala]

On Wed, 2009-09-02 at 16:59 +0200, Reimar Döffinger wrote:
> On Wed, Sep 02, 2009 at 05:04:26PM +0300, Uoti Urpala wrote:
> > I don't see how FFmpeg changes would be all that helpful. So what if you
> > do VDPAU usage negotiation at the colorspace level instead of the
> > decoder level? Could you somehow avoid cases like "we selected a VDPAU
> > colorspace but it turns out it doesn't actually work, need to go back
> > and try something different"?
> 
> Do I really have to make a list? Changing FFmpeg code means:
> 1) We can get rid of the extra decoder list in codecs.conf that needs to
> be maintained

How is the user supposed to configure using the VDPAU or non-VDPAU
decoders? Those are quite different decoder implementations and
selecting them with '-vc' seems natural. Is the user supposed to give
options that specify colorspace-selecting filters or something?

> 2) FFmpeg then again has a 1:1 mapping codec_id -> decoder and generally has
> cleaner code

I haven't looked at the relevant FFmpeg code closely enough to say
whether such a change would make it cleaner or not, but anyway that
wouldn't directly help MPlayer even if true.

> 3) We already have code to try a different colour space, so for cases
> where we can detect issues during colour space query we don't need any
> extra code

I wasn't talking about cases where you could detect the issues "during
colour space query". Do you have reason to believe cases where issues
are detected later would be particularly rare?

> 4) In particular using filters will automatically and completely
> magically cause a fallback to software decoding without any extra code

IMO it would not be a "hack" to work around brokenness or anything like
that to make the code explicitly aware of filters not working with
hardware decoding and give clear messages to the user.


> > If you can't then implementing the needed
> > retry and fallback mechanisms at colorspace level could well be more
> > work than using the existing decoder-level fallbacks.
> 
> There is nothing to implement. That is the whole point. It is all
> already there, just the braindead approach of using a different name
> just to enable a feature of a decoder broke it.

There is no existing code to handle problems which are found after
colorspace negotiation, and the problem that started this thread is one
such.

The decoders are quite distinct with different features and problems, so
IMO talking about "just enabling a feature of a decoder" is misleading.

> Yes, after that fallback will still not work in some case. And in some
> case like a meteor having hit the computer it will never work.

To me it looks like the failure cases occurring after colorspace
negotiation are quite a lot more relevant than a meteor hitting the
computer.

> The point is by simply cleaning up FFmpeg code some important issues
> will simply be gone and I refuse considering adding hacks when a code
> cleanup would probably fix things good enough. If it doesn't you start
> at least from cleaner code.

I don't see any major technical advantages in selecting VDPAU usage at
colorspace level instead of decoder level. It's different enough that
trying to handle all differences "automatically under the hood" is not
particularly useful. The user configuration options fit better at the
video decoder level.