[MPlayer-dev-eng] Enhanced cropdetect code

[Roger Heflin]

Reimar Döffinger wrote:
> On Sun, Jul 06, 2008 at 04:53:58PM -0500, Roger Heflin wrote:
>> And I had not heard the "0-th order entropy estimation" as a name for it, I 
>> heard about it 15+ years ago in an image processing class used in reference to 
>> compression algorithms, and it is somewhat useful for estimating how well (in 
>> general) things could be compressed, and would run at disk speed-which at the 
>> time was much much faster than compression algorithms.
> 
> Well, it is called 0-th order because it only estimates the compression
> in case each symbol is coded independently, i.e. the context in which
> the bytes appear is completely disregarded. As such it is not very
> realistic with any real compression algorithm, though it is nicely
> fast and simple (e.g. with this method, the sequence 00001111 and 00101101 would
> be estimated to have the same entropy/"compressability" which does not
> quite match reality).
> 
> Greetings,
> Reimar Döffinger


I did some benchmarking.

The original cropdetect that does not actually crop much at all (so it would run 
faster since it is not cropping anything) but still takes 85 seconds to run on 
my test case.   My test case is 4000 frames of a 1920x1080 ATSC recording.

Original non-working cropdetect:        85 seconds
Original -vf cropdetetc=255 (cropall): 205 seconds
1st version entropy code:              146 seconds
All math changes:		       141 seconds (not much of a gain)
Table the log2 calcs:		       134 seconds.
	(currently 4096 entries should this be larger, or coded to be some
	 other limit that is already in mplayer?).
Entropy -vf cropdetect=24 (cropall):   311 seconds



But even the starting number is less than 2x worse than the original cropdetect 
that does not work for this case at all (no cropping).

I am thinking to modify the cropdetect option like this:
	-vf cropdetect=24:12
with the second parameter being for entropy detection, default entropy level 
will be 0 and no entropy detection will be done, if one were to use 
cropdetect=0:12 then old cropdetect would be disabled, and entropy cropdetect 
enabled, if there are numbers in both, then it does a OR of the two, if either 
says to crop then it crops.

I believe this won't change old functionality, and add a new cropdetct options.

What about adding a 3rd option onto cropdetect that allows skipping of frames ie
-vf cropdetect=0:12:30 says only check every 30th frame?

                                       Roger