[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 15:09:54 -0500
> "Daniel Manjarres" <danmanj2 at gmail.com> wrote:
>
> > > 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.
>
> By definition, nothing you can do will make a 4:3 video fit on a 4:3
> monitor any better, so I don't have any idea what you're trying to say
> here.


Sometimes people have 4:3 content that they want to broadcast over ntsc
video. But when they broadfcast they have to deal with ntsc overscan, where
any where from 3-5% of the pixels fall off the visible part of the TV
screen, so there are 2 ways to deal with this: either make sure all the
important stuff is in the middle, and let the overscan cut off stuff around
the edges which isn't important, or shrink the true content a few percent to
make sure everyone sees everything you were trying to broadcast. When
somebody turns around and does a vidcap of that shrunk 4:3 content they get
black bars around all 4 edges of the picture in the overscan region, since
computer monitors don't have overscan. I want to remove those overscan
compensation bars. So that's one thing you can do to make 4:3 ntsc content
fit a 4:3 computer monitor better.


> 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.
>
> You only sent it yesterday, you shouldn't expect much this soon.


I know I need to get more attention, but i'm a not a good attention whore.

Plus, your script is rather specialized.  Most people wouldn't need or
> want -x -y explicitly specified, or using -vf expand instead of hardware
> to add borders (slowing down playback), etc.  And as I've mentioned,
> there are some easier, faster ways to accomplish most of the same
> results.



The -x -y and -vf expand are small implementation details tuned to my usage,
they can be changed easily to suit other people. The cropdetect strategy is
the big thing I am worried about right now. But really, does -vf expand take
more CPU time? I had not noticed. I would have thought that the -fs
paramater didn't have some special code path to draw static black bars
faster than -vf expand does, I would have thought they did the same exact
thing.