[MPlayer-dev-eng] vdpau codec priority?

[Reimar Döffinger]

On Wed, Sep 02, 2009 at 05:04:26PM +0300, Uoti Urpala wrote:
> On Wed, 2009-09-02 at 15:39 +0200, Reimar Döffinger wrote:
> > Anyway I'm not interested in endless discussions, I only wanted to say
> > that from my point of view the FFmpeg end must be fixed first,
> > everything else is just hacking around with probably little effect and
> > more effort.
> 
> 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
2) FFmpeg then again has a 1:1 mapping codec_id -> decoder and generally has
cleaner code
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
4) In particular using filters will automatically and completely
magically cause a fallback to software decoding without any extra code

> 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.
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.
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.