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

[Daniel Manjarres]

On 7/2/06, RC <rcooley at spamcop.net> wrote:
>
> On Sun, 2 Jul 2006 09:39:46 -0500
> "Daniel Manjarres" <danmanj2 at gmail.com> wrote:
>
> > Would that work for a non wide-screen display? I wrote this script in
> > a general enough way that it also works for 4:3 screens.
>
> With a 4:3 video on a 4:3 display, -panscan wouldn't do anything, for
> obvious reasons.



Except if you have 10 pixels worth of overscan padding on the top and bottom
you will still have those wasting screen space on your monitor. It may seem
dubious to lots of people, but if there are bars taking up 5% of the
vertical space on my monitor I want them gone, regardless of if I am using a
4:3 monitor or not. It is not a big enough annoyance to write a program
over, but since I was already writting one I figured I would take care of it
as well.


> Ok, now do it with white letterbox bars and I'll be happy.
>
> I don't have any such videos, nor have I ever seen one (same goes for
> grey borders), so it's rather difficult to come up with a solution for
> them.



No problem, we all write scripts that handles the files we actually use. I
have 2 files with white letterboxes, and one with grey. It seems to have
become more fashionable to use white on some TV stations.


> > Speaking of which, a round parameter of "1" won't work.  2 is the
> > > minimum.  Few formats can be cropped to odd dimentions.
> >
> > Oh yeah, It was 2 before, but crop detect outputed a y size of 404 and
> > a y offset of 2 for a file with a height of 405 (404 + 2 = 406, 406 >
> > 405) so it wouldn't play, so I changed it to a round of 1 with -zoom
> > to make it work on that file.
>
> I don't think I was clear enough.  A round value of 1 is just ignored.
>
> vf_cropdetect.c line 117:
>     if (vf->priv->round <= 1)
>       vf->priv->round = 16;


Wow. And if I had liked that file I would probably have noticed, but I was
just happy that it started up after I changed round to 1, and didn't
actually watch it. Now I guess I have to set it back to 2.


And you should upload that file with un-even dimentions so someone can
> reproduce that problem, and fix that bug in MPlayer.


I'll probably just fix it myself.

> I am curious about your script, why don't you post it so I can try it
> > out?
>
> Attached.  It's part of a much larger encoding script, so it's not very
> user-friendly in this form, or fast.  You can speed it up by:


Leaving aside how to speed it up, I like some of the ideas in the script.
Majority rules cropping, huh? That's a different way of approaching the
problem, I like it.

As a speed comparison, on my system your script took 4.142 seconds to run
against my gray letterboxed file, my script took 5.8 seconds. The  file is
310 seconds long, so it corresponds to 8 loops at your 35 second sample
interval. I changed it to 25 seconds to get the full 10 iterations, and then
it ran in 4.5 seconds. Anyway my script took about 1.7 seconds longer, and
correctly cropped the gray bars on the top and bottom. Your script needed
the crop detect threshold adjusted to 46 (!) to get rid of the bars (i hate
adjusting it, why can't it be automatic?). Of course it wasn't designed to
work on white letterboxed files, so it didn't work there as expected.

Anyway from experience I have files with a 4 second blank right at the 34
second mark (my first guess at where to sample was @ 34 seconds), so
sampling at 35 second won't work there, and the file is less than 70 seconds
long, so the output of your script is:

Crop Setting is: crop= ...

(the problem is that since 9 of yor samples are beyond the end of the file
the winner of the majority rules crop detect parameter is the NULL string,
you need to adapt the length of the file, when I looped the file 6 times
your script works)

This would probably be your script's first failure to at least play the file
even if cropdetection goes bad, because the script didn't catch an
exception. Unless you caught it somewhere below that, which is likely if you
pass another filter to -vf, and have the crop be the last filter param, in
which case mplayer ignores the trailing comma seperator. But without another
video filter, or as the first video filter your larger script breaks. I
expect my script breaks on other people's files too, that why I need more
test coverage.


reducing the number of rounds


Reducing the number of samples reduces accuracy and  speeds it up, but
uniform  sampling is the worst way to sample this sort of thing. Google
"chebyshev points" for a unrelated, yet related topic. If you want the best
accuracy from a small number of samples you pretty much never want equally
spaced samples.

using -vo null instead of md5sum (old bug)


3 consecutive run times: 4.7 seconds, 4.1 seconds, 4.0 seconds. Not a big
difference.


using -nosound instead of -ao null



4.2 seconds, 4.2 seconds, 4.1 seconds

removing -identify and related code


4.0 secs 4.1 sec 4.3 secs.

using pipes instead of intermediate files


I don't think that is a speed up at all. Awk runs pretty fast nowadays.

The best/only speed up technique is to use fewer non-uniformly spaced
samples at points that adapt to the length of the file and fewer frames per
sample.

> do you handle that case, or is there some paramater to force
> > cropdetect to not print crazy numbers?
>
> None of the above.  I suppose those "crazy" values are just
> statistically insignificant in my script.


They are just values you never ran across in personal testing. I can make
your script spit out negative values by changing it to sample only once, at
34 seconds instead of 35, and only capture 10 frames instead of 20,  and
adding more samples just changes it to spitting out the NULL string as the
winner of the majority rules contest. Fixing the majority rules so NULL
can't win is easy, and adapting the sample points to the length of the file
isn't so hard, but I already have my script working, so I'm not going to do
it. If somebody wants to play around I'd say keep majority rules, but select
samples from a list of times, 35, 79, 102, 154, 199, 212, 450 and 800
seconds for instance, and weight the samples by the number of frames taken
at each point when counting the votes. It might work even faster and better,
but it will still not handle too high of a black level or white letterboxes.
Maybe several runs at different cropdetect thresholds can be compared to
avoid the need to manually adjust it, but by that time my script will be
running faster. In fact, multiple runs with contrast set to -1 can invert
the picture luminance, and probably detect the white letterboxed files, but
it will still be slower, or as slow as the script that I already uploaded.

Thanks for the file, I bet it is one of the best orthodox cropdetect
scripts, and it did give me some ideas, in case my script falls down against
other people's files, but so far nobody has written to me to say they have a
file that my script fails on. I am guessing that is because nobody has tried
it seriously. I'll keep hammering on it so I can get some search results up
on google, for the next Joe who cares someday.