Comskip is Fast already - but would this work for faster?

[Questor]

Hello Erik,

1. Video 'sampling' to find program/vs commercial probabilities then scan to find begins & ends.
2. For movie channels (AMC, TCM, HBO, etc.) the parts to cut occur only at the beginning and end...are there options for this?

I note in the .ini file there is an option to skip frame(s), but default is off.
There are some features of commercials that might make quick scanning possible.

On a show with large frameborders it would be simplest, but maybe other types of programs also.

Suggested process -
1. scan from beginning of video until reasonable sure of 'program' and not intro or commercial
2. gather a sample of 1/2 seconds of video at each 5 second interval from the rest of the mpeg
3. perform same type of analysis as now for each sample (ate as show or commercial)
4. once this is done you could scan forward from each pre-commercial show or pre-show commercial block to find
the joining point (low noise, black frame, etc.)

For added speed I suppose a thread could be setup to use the to seek in the file to each of the
5 sec offsets and read the 1/2 second while the main thread could be using the mpeg library for the analysis.

I don't know what functions the library has, perhaps it has seek operations already, but with variable length
frames due to compression...after seeking scanning the mpg to find the beginning of GOPs would be necessary.

[erik]

The approach to selective seek for commercials based on certain hints is possible but will require a large effort from my side. To decode a random frame one must at least decode 15 frames before, just to be sure to catch the I frames.
Another problem with seeking is that the PTS of many recordings is not reliable where counting frames from the start proves to be reliable.
Currently the high speed donation version can scan HD on a "normal" CPU at at least 4 times realtime per core. This will allow you to keep up with Comskip on one core when recording from 4 tuners.

[Questor]

Aha... so

counting frames from the start proves to be reliable.

would imply that another possibility (not speed in this case) might be...since you count accurately from the beginning all frames and presumably time...

Would it be possible to write code to correct any discovered GOP timecode errors?

Since this would be editing existing data-in-place with identically sized data (the format is binary, and allways the same size) it could patch an existing stream.