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

[Rich Felker]

On Fri, Aug 26, 2005 at 01:31:36AM +0100, ObsessiveMathsFreak wrote:
> 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 

That's because it will inherently slow things down in some cases.

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

I don't see any reason why it should. Taking screenshots is not a
normal function of watching a movie..

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

There is no way to give a "what you see is what you get" output. It
simply does not exist, since the scaled video only exists on the
phosphors of your crt (cells of your crappy tft) for a split second.

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

They're not incorrectly sized but correct. They should just have
different horizontal and vertical dpi in the png header to indicate
the nonsquare samples (however I imagine vo_png is broken and does not
set these headers correctly).

If you wanted the pngs to be resampled you could use the -zoom option,
btw. However this is stupid as it will lower quality and waste space.

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

.... I won't even reply to this ...

> At the moment, each vo is supplying its own rescaling 
> code, and those that don't, i.e png, are getting it wrong.

There is no rescaling code. Rather, there's just no requirement that
samples be square. Learn a little bit about the subject before telling
us we're doing things wrong, why not?

> 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?)

Yes, however it can't be done with the current mplayer design without
it being slow. :(

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

:)))))))))

Rich