[MPlayer-dev-eng] [patch][rfc] screenshot. Aspect Ratio problems

[ObsessiveMathsFreak]

Hello all.

I've recently been trying to compile the vf_screenshot.c patch into 
Mplayer. I managed to succeed, and could indeed take screenshot. However 
there were several problems.

Firstly, a minor issue. As it is a video filter, one must first tell 
Mplayer to use the filter, and for some reason, with my vo 'xv', I had 
to wrap the filter around two scale filters for it to work -vop 
scale,screenshot,scale. Go figure.


I think having the screenshot function as a video filter is probably 
conceptually wrong. The way it is currently used, the filter is called 
every frame, but usually does nothing(only get to business when a key is 
pressed). A bit of a waste, hence, it would be a bad idea to turn this 
on by default. And really this should be a function that is turned on by 
default.


The second problem, and this is a much more fundamental one, has to to 
with how mplayer seems to be dealing with aspect ratios.(I know next to 
nothing, so if I'm wrong here.... admonish me!)

I've got a 720x560 input video, which is muxed in a matroska container. 
I use mkvmerge's --aspect-ratio or display-dimensions option to rescale 
this to 768x560(this movie is a crop, the original was 768x576).

Now Mplayer will play this fine, but the screenshot filter will not give 
a 'what you see is what you get' output, instead giving a 720x576 png 
output. (Xine does this too, so you're not alone here)

The problem it would seem, is that the rescaling requested by the 
matroska container is not being done until output. In other words, it's 
being left to the vo 'filter'.  As such each vo filter is applying its 
own internal aspect ratio resizing, or what have you.

I'm almost positive about this, because the -vo png 'filter' has no 
aspect code, and indeed also gives the incorrectly sized pngs. (720x560 
instead of 768x560.)

I don't know if this has to do with the muxer code or not. The way I see 
it, if mplayer sees an aspect ratio rescaling header in a mux container, 
it should apply a separate scaling filter before anything else, 
including vo. At the moment, each vo is supplying its own rescaling 
code, and those that don't, i.e png, are getting it wrong.


This is the biggest problem with a WYSIWYG screenshot feature. Also, the 
feature is unable to capture subtitles or OSD information. I would feel 
that it should eventually be able to do this, possibly also taking the 
effects of previous filters.
(Shouldn't stuff like subtitle overlays etc.. be moved out into filters, 
rather than having each 'vo' filter implement them separately?)


That was my sorry tale at any rate. I hope I have been of some help to 
the far far greater project that is mplayer. Either that or I am an 
irritating curmudgeon.

P.S.
To avoid conflict with the 's' for gui stop, I used the '@' key to take 
screen shots. Just an idea, should you ever apply this.

P.P.S.
mplayer.c is over _4000_ lines long!! If it gets any bigger, it will 
reach critical mass and collapse into a black hole!!