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

[Daniel Manjarres]

On 7/2/06, Ivan Kowalenko <ivan.kowalenko at gmail.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jul 1, 2006, at 21.23, Daniel Manjarres wrote:
>
> > Oh yeah, I forgot to talk about ntsc overscan, and how to avoid
> > losing part
> > of the video to overscan sometimes broadcasts are letterboxed on all 4
> > sides, which sucks when played back on a computer where there is no
> > overscan. Also simple cropdetect fails if your crop detect window
> > falls on a
> > purely black part of the movie.
>
> Well, that's not THAT big a problem. If we're talking about a pre-
> recorded or stored video file, grab the aspect data out of the file
> (assuming we're dealing with overscan ONLY), jump forward thirty
> seconds, running in video decoding only, null output, benchmark mode,
> and then use CropDetect and have it run until it gets something near
> the proper aspect ratio.


Good idea, but it would only be easy if the script had prior knowledge of
what it is supposed to do, like have a script for overscan bar removal, one
for letterbox removal, one for foo correction. I am not doing that. I am
writing one script to work on EVERYTHING. So the script cannot have prior
knowledge about what the correct thing to do is, or take shortcuts.


The problem is when you have non-overscanned material, but straight
> up letterboxed stuff, where the aspect ratio can't be pulled from the
> file (either as resolution data or metadata), and things like Red vs.
> Blue where something like 2.35:1 (Don't know the full res) is jammed
> in 4:3 and they stick subtitles in the blank space below (Lopez is
> hard to understand, even if you understand Spanish!).



Ok that is a new test case for me then. Are the subtitles ALWAYS below the
video? If so I can just make it expand the softcrop region preferentially
down with a different value for the $recenter variable. That would probably
work even if the subtitles were not present in the sampled frames. If I rent
this movie and get brain damage from bad acting while trying to make it work
will anybody appreciate my sacrifice? :-D If it's a bad movie maybe I should
let it slide.........

XBMC has a feature very similar to what you're crafting for MPlayer.
> It's VERY useful, but it does happen to have the problem of cropping
> out RvB subtitles. You might want to check out how the XBMC crew
> manages to make this work.


I can imagine how it works, and if it is cropping out subtitles then I kinda
don't want to emulate it. Really this is not rocket science; I am getting my
PhD in electrical engineering, and have done lots of video signal
processing, I know what it takes to do this on a given set of files, and you
don't need a master's degree to think it up and implement it. The problem
is: do I use the super accurate fool-proof slow algorithm or the
just-barely-works fast algorithm. This script falls in the just barely works
category, but barely 100% is still 100%. If I get feedback from people that
this script doesn't work on 100% of their files and I can't see a way to fix
it, I'll have to abandon it and switch to a program in C because the
heavyweight algorithm is too slow to script.


Given that XBMC is also an OSS project,
> and given that they're relying on MPlayer for their project, I'm sure
> they'd be willing to collaborate on this.



I'm sure they are nice people, and know what they are doing, and are already
working on improvements to their feature, but if I can just get people to
test this script and send me their failure info I can do it myself.

Later.