[MPlayer-advusers] enable vo at compilation message and automagic , scale filter retry.

[Oded Shimon]

On Thu, Oct 06, 2005 at 10:28:29PM -0400, tempn at twmi.rr.com wrote:
> e.g.  when luser wants to use -vo x11 and he asks why he
> gets message like 
> Error opening/initializing the selected video_out (-vo) device.
> can it also say 'vo x11 not enabled, please enable at compilation'?
> or 'vo asdf not availible vo, maybe you made a typo?'
> because currently it does not say if luser has vo or not.
> 
> also...
> 
> Could not find matching colorspace - retrying with -vf scale...
> Opening video filter: [scale]
> The selected video_out device is incompatible with this codec.
> Also try adding the scale filter, e.g. -vf spp,scale instead of -vf spp.
> 
> FATAL: Could not initialize video filters (-vf) or video output (-vo).
> 
> can mplayer be made to automatically try adding ,scale to the
> filter list??? this would fix a lot of colorspace/filter problems, no?
> i think mplayer tries to add scale, but it does not help. retrying
> playback using -vf fspp,scale would fix it (as it does with my display)
> 
> see? instead of this message
> "Also try adding the scale filter, e.g. -vf spp,scale instead of -vf 
> spp."
> it could just retry automagically without user intervention.

The problem (as always...) is MPlayer's design.

There's a step where mplayer checks if the vc, vf's, and vo, all use 
compatible color spaces. there are few filters which actually change the 
color space, most just pass it through., so, what you have is this - the vc
sends a question, "is this colorspace ok?", this questions rolls right 
through all the vf's until the vo, and then returns success. if any single 
vf is incompatible, it fails immediately.

int myvf_query_format(fmt) {
	if (fmt == YV12) { // ok for me, now let's ask the rest of the chain
		return vf_next_query_format(fmt); // "recurse" to next vf, until vo
	}
	return 0; // I can't handle anything other than YV12, error.
}

and now, all the vc has to do, is ask the first filter, if it likes this 
colorspace, and in a "recursive" call, the rest of the filters are also 
checked. If it returns success, all is well and we can start playing. Now, 
if this fails, the vc has absoloutely no idea why or where it failed. it 
could be the vo didn't like it, it could be some vf in the middle, it could 
be anything. it makes one desperate attempt to fix this: add a "scale" to 
the begginning of the chain. "scale" can convert just about any colorspace 
to any other colorspace. if after this, it STILL fails, it gives up and 
throws an error (or, if possible, usually with the dll codecs, it tries 
another colorspace. i.e., the vc can output rgb, yv12, whatever you 
preffer, so it tests them one by one - actually, i'm not so sure about 
this. whatever).

Adding scale at all is just silly, the only reason it's done is because 
vo_x11 doesn't support any colorspace except rgb, and most vc's only 
support yv12. so without adding scale automatically, almost nothing would 
play with x11.
Your suggestion is to add scale to the END of the filter chain instead of 
the begginning. it somewhat makes more sense, as it is usually the vo which 
is the one that doesn't accept the colorspace, not one of the vf's. But 
it's still a hack, just a different flavor...
The only CORRECT thing to do would be to add scale right in the 
violating place, although imo this is suboptimal too, vf should be purely 
decided by the user, not by mplayer...

maybe we should do something like -af-adv for vf :)

- ods15