[MPlayer-users] please help test my mplayer widescreen converter wrapper script

[Daniel Manjarres]

On 7/1/06, RC <rcooley at spamcop.net> wrote:
>
> On Sat, 1 Jul 2006 14:31:07 -0500
> "Daniel Manjarres" <danmanj2 at gmail.com> wrote:
>
> > and weighs in at 509 lines.
>
> Apparently 50% of which are full lines of comments.


Yep. Comments. I love them.


> 1) it can crop WHITE letterbox bars. AND rainbow bars. AND statio ID
> > logos. And popup titles (like in music videos).
>
> I've never come across any of those, however, it sounds like what you
> want could be easily accomplised with -vf dsize.  Tell it your screen
> width, let it scale (in hardware) the heigh to match, and the horizonal
> bars of a 4:3 letterboxed video will simply be off-screen.


Cool, but not a complete solution.  I have files at "4:3" which are
letterboxed with VERTICAL bars too. Lots of movies do not use the whole
resolution of the file that contains them, and not always in predictable
ways (like the electricsheep screensaver mpegs). I don't want to have screen
space wasted displaying static color bars anywhere. Once I throw in the
possibility of white letterbox bars I have to do special processing anyway,
so I might as well have complete control over the crop. Also I HATE HATE
HATE having to manually adjust the crop threshold. I have ntsc video
captures that have a "black" level _above_ a cropdetect threshold of 35. No
simple cropdetect script is going to work on those files AND other files
which have very dark lighting around the edges of the real video region.
This script works on EVERYTHING I have thrown at it. 100% everything.


> 2) it skips the begining of the file so it does not get confused by
> > intro graphics or titles
>
> That's quite easy to do with cropdetect.


Let me rephrase: It samples an adaptive number of frames at 5 different
points in the file adaptively selected according to the file length. If I
wanted to just fast forward 60 seconds and run cropdetect from there it
would be easy, but I have files less than 60 seconds long. So I have to do
some more work to make sure I am getting the important frames, and not a
intro or trailer with a different aspect ratio. I didn't start out with 5
samples, I started with 1. It grew to 5 when I impossed the requirement that
it work for 100% of my files. And it does work perfectly with all of my
files. The alternative, skipping n seconds in and runninfg for m frames
fails on "the hitchhicker's guide to the galaxy" spectacularly.


> 3) it is aware of the screen aspect ratio, and optionally matches the
> > crop to fit the screen
>
> I'm not sure what you mean here.  If you have something wider than
> your display, does it overcrop the width (which -panscan 1.0 would do),
> or undercrop the height to match the display
> (leaving black borders, which -vf dsize would do)?


It will start by deciding if it has to increase the crop area vertically OR
horizontally. On my system with a 1.6:1 monitor a file which contains a crop
area that is 4:3 will have the crop area widened symetrically, while a file
with a crop area that is 2.35:1 will have the crop area get taller
symetrically. It handles all cases of running into the end of the movie
frame correctly, and will keep expanding asymetrically if it hits an edge
and the recenter variable is set. This is an option, I actually like seeing
whatever pops up outside the main video sometimes (say a title), and
othertimes like to not see it (say staion ID logo).


> 6) It adds black (sometimes gray; mplayer bug) bars to the

> > re-letterbox the active video area to fit the screen
>
> Why not just let -fs do that part?  Also, -vf expand=aspect=$H/$W should
> do the same thing.


Well the answer to that is that -fs is broken. I have my desktop at
2560x1600. Yes 2560x1600. I routinely work at resolutions lower than that,
but if need be my monitor will go that big. -fs ignores the CURRENT
resolution and tries to scale up to 2560x1600. -vm doesn't handle crashes
correctly, so half the time mplayer leaves me with a screen at some weird
resolution. I wrote the script so that mplayer will NOT change the monitor
resolution, and will NOT try to scale up to 2560x1600 when I am at 960x600.
Specifically, I run mythtv at 960x600 using the enlightenment window
mananager's ZOOM to make it full screen. If I select a video to play I want
it to be shown at my current screen resolution, since mplayer has never been
able to restore both the video mode and the pan location of the 960x600
video within the 2560x1600 desktop. It always leaves me someplace else, and
I don't want to get up off the couch to move the mouse so I can see the
window I was just looking at before mplayer did something ignorant of my
setup.


> It just seems like you could have done all this with a lot less work
> (and a lot less time waiting before playback finally starts).


See the comments in the code, and the output as it runs. A LOT of time is
spent waiting for mencoder/mplayer to seek to the sample points in the file,
which should be instantaneous. I mean really, transcoding the video and
diffing the frames takes less time than waiting for mencoder to output the
video? why? And when I scan to see the length of the video, and it's too
short mplayer waits around to see if maybe the file gets longer before
returning. So playing a 15 second clip takes forever. There is lots of room
for improvement in the script regarding speed, but it's not a problem in the
algorithm, it's a problem in driving mplayer to work as fast as it can,
which you sound like more of an expert at than me. Also I am perfectly happy
to wait 7 seconds for the playback to start knowing that it will work 100%
perfectly on any file I throw at it, rather than getting annoyed that 10% of
the time that it doesn't work because of a high black level, or white bars,
or titles that pop up and scre up the cropdetect. I would be happier if it
only took 2 seconds though.

> The program is brittle. It depends on the console output of mplayer,
> > which seems to change for no reason every few months.
>
> I think you'd save yourself a lot of trouble if you used -identify
> instead of always trying to parse MPlayer's output for things like
> aspect, width, height, etc...


DING DING DING! Great idea, why didn't I see that in the mplayer man page?
(oh yeah, it's 2000 pages long) Oh well, that's why I posted it here. Other
people know stuff that I don't know. I also posted it so that when some poor
guy googles for mplayer crop he hopefully finds something better than what I
found, which is just the 5 line cropdetect script that doesn't work
sometimes, or instructions on how to do it manually.

Despite changes to mplayer, my cropdetect
> script hasn't broken in the past couple years, since I've started using
> it, nor does mplayer ever crash inside the script AFAICT.


Feed it a bad file, and it WILL crash :-D  It happens to me all the time (ok
that's an exageration), and it is unacceptable to have it leave my monitor
in a weird state afterwards, ergo no vidmode switch. Seriously on amd64
mplayer seemed to crash 5% of the time for no reason until recently. The
part of the script that is brittle is the crop detect. It will ALWAYS at
least play the file if that fails, so it's not brittle in that regard. When
I said 100% of all my files I include 100% of my broken corrupted files.
Even if it crashes mplayer it will still at least play, and by breaking up
the samples in different mplayer invocations I can still get a good crop
even if one of the samples falls on a corrupted frame that crashes mplayer
(In fact I had to move the sample points around to avoid crashes or video
corruption that confused the crop detection in 2 of my files).

Anyway thanks for the ideas. This is the perfect time to repost the damn
file with some obvious bugs removed, but I don't want to send an attachment
out twice in such a short time. The bugs were related to the variable names
for the fifth set of sample frames. I left them named foo4 instead of foo5
when I copied them.

Later