[MPlayer-users] Re: Cropdetector

[rcooley]

On Thu, 22 Jul 2004 16:43:37 +0100
Martin Collins <martin at mkcollins.org> wrote:

> With some material it can give dodgy results. 

cropdetect is as reliable as you allow it to be.  

> For example I have a
> video of some wire-frame graphics with a black background. Everytime
> the graphics change so does cropdetect's output.

cropdetect, unless it's been changed recently, will find the border for
a frame, then start on the next frame.  If it sees a frame with larger
dimentions, it changes to match the largest, and keeps the largest, even
if it finds a frame with smaller video dimentions (larger border).

So, the more frames you let it process, the more accurate it should be.

> I only encode one or two things a week and they take several hours. A
> couple of minutes to get it right first time is a small price to pay.

Well, I don't know about you, but encoding video doesn't do me any harm.
 So, even if the dimentions are wrong (which they very rarely are for
me) it doesn't matter if it's been working on it for hours, because I'm
not forced to sit around watching it, and thinking about it. 
Wasting several hours of CPU time to save myself 5 minutes is a very,
very good trade IMHO.  It's even more valuable because trial-and-error
croping is a real mind-numbing experience, plus, it's very rarely wrong,
and it only takes 2 seconds to preview the output and stop the script in
the event of a cropping problem.  Oh, I should also mention that
trial-and-error anything is much more difficult when you are doing it
using only a remote control.

> I'm already spending longer editing out ads etc.

Really?  Only takes me about a minute to remove ads from an hour-long
show.

> Besides, cropdetect will run through the whole video if you let it.
> How do you stop it in a script? 

You don't top cropdetect, you stop mplayer.  -frames

> How can you be sure you have a representative sample?

Well, you can never be SURE of anything.  However, there are plenty of
ways to get good results.  Right now, I just use a reasonable
"-ss", "-frames", and "cropdetect=" value, then choose the last one
cropdetect outputs. I also have a patch to cropdetect which rounds down
to multiples of 16 (which is very good, because cropdetect always
leaves an extra 2-4 lines that should be cropped, especially in
videos with fuzzy borders, or interlaced material.)

However, I've been considering statistical analsys lately, to make
99.99% sure you've got the best parameters cropdetect can provide. 
Basically, the script I've written (I haven't started using it yet)
launches mplayer 10 times, with different -ss positions (once every
minute to be exact), then takes the parameters cropdetect reports each
time, and selects the single value that was reported the most times.  If
you're paranoid, you could ramp that up to many more times if you
like...  

Or you could just let cropdetect run through the whole video, and tell
you what it thinks it best :-)

> On reflection though, maybe the maximum would be better.

Indeed.