[mythtv] PATCH: Commercial detection/skip using blank frames

[Bruce Markey]

Chris Pinkham wrote:
>>>Shouldn't uncompressing hardware-compressed frames and sampling them
>>>still be faster than software compression?  It's not as though we have
>>>to re-encode them when we're done checking for blanks. :-)
>>
>>Ya. I had come to the same conclusion but didn't want to
>>suggest it in the context of this message. If the system
> 
> 
> There are a couple factors that might make that a bad idea for most.
> If someone is using hardware compression (with current hardware compression
> support), then they are probably using it because they are short on
> horsepower anyway.  The current hardware support uses MJPEG anyway which
> is cpu intensive to decode as well. 

I agree with both these reasons. Along with the other reasons
I mentioned, I chose not to suggest it originally. I was
acknowledging that Andy made a valid observation but I'm not
convinced it's the right answer.

>>just to check for blank frames. However, the decode to check
>>for blanks could be done just as easily in post-processing
>>which is what Chris was looking into anyway. If someone
> 
> 
> I'd rather do it realtime if it doesn't take too much cpu.

But as we're seeing, I/O is the time culprit for realtime
during playback. Optimizing the code only chips away at the
final 1%. I did some skips in the Lakers game tonight and
couldn't help notice the HDD LED on solid until the skip
finished ;-).

But if you meant realtime during recording, ya, that's clearly
a win for software encoding. A tougher call for hardware MJPEG.

> Post-processing
> will introduce other factors, such as if I'm recording 2 shows in a row from
> say 8-9 and 9-10, I don't want my cpu to spike to 100% utilization at 9
> because the first show is being processed for commercials (which you would
> normally want to run as fast as it can).

I don't think it's a good idea either. I was just referring
to the post-processing tests you had done to get framerate
stat and though you were considering that approach.

Right now, I think a practical solution might be to write
out a file with a .blanks extension (or whatever *) while
recording. A list of blank frame numbers would be under 100K
compared to 1GB or 2GB per hour video files. During playback,
check for a .blanks file. If it doesn't exist, fine, just
do the I/O intensive seeks that you already have working
well. If the .blanks file does exist, read it into memory
and run the skip code using the blank list for nearly
instantaneous skips.

I've probably done too much shoulder surfing already ;-).
I trust you'll find practical solutions.

--  bjm

  * There is a convention of having other files with with
the same *.nuv name and an extra extension. These should
be deleted along with the video file in SpawnDelete .