Couple of ideas from a PVR addict :)

[colin]

I would imagine they have included scene change detection as going from program to commerical would have a scene change in it.

Tough module but will be a good one,

Colin.

[CodeMonkey]

Yeah that's what it looks like. You can enable/disable blank detection and scene change. I don't think it's meant to run both at the same time.

[craigg75]

Myth is somewhat difficult to get running still. I was never able to get it running even using the newb guides using redhat . If you're a linux power user it's probably a cinch. Is there the ability to skip ahead 30 seconds with gb-pvr? BeyondTV has this ability plus you can skip back 7 seconds. These time frames are all configurable too.

[sub]

The skip keys current skip forward or back 60 seconds, but you can change this to any period of time by typing a number of seconds before pressing the skip button.

[BerkA]

I love this idea.

However, I feel that you may not have to go all the way into automating it. A simple fade-out detection and indexing could be enough. Then the user could find the appropriate fade by just pressing the skip buttons a few times.

How would this be? At least as a first step.

[martyc]

Colin - I didn't know that was what the symbol in the top right corner of the screen was for although it now makes sense.

BeyondTV seems to detect fades (i.e. a fade to an advert) and generates a small xml file with timecodes in it, you can press the up or down arrows on the remote to skip to/past these timecodes. I think this would be the way to go with GBPVR rather than automatically skipping adverts, it would be too easy to miss bits of shows.

[sub]

I dont think we'd skip automatically but rather allow you to press the skip button to jump to the next known cut point.

[CodeMonkey]

That's sub's call. I'm just going to give him the cut information

[BerkA]

I did some casual research in this field. I feel that there may be solution that doesn't involve decoding the MPEG stream/program. This would *SIGNIFICANTLY* reduce the amount of time necessary to generate cut lists.

(Sub had mentioned decoding in a post to the "Developer" forum under "plugin ideas" -- I'm assuming this is the direction you're taking)

I think that we can use the compressed frame sizes as a cue. This may not be as accurate, but it could prove to be a worthy compromise.

I downloaded a program that allowed me to look at the frame-by-frame statistics of one of my recorded programs. http://www.elecard.com/download/#StreamEye

As I had expected, compressed frames get noticably smaller when they're blank frames. This is quite noticable on the I-frames, but the other frames are helpful as well. (e.g. when a short fade falls between I-frames)

Check out these pictures:

This picture shows a longer fade at the end of a program, before the commercials:


This one shows a series of shorter fades. #1 and #2 are quick fades between commercials. #3 is the fade before the program starts.


What do you think?

If I can somehow get a CSV file or something that has the frame info I need, I can work on an algorithm/signal processing to detect the cutpoints. ( I couldn't possibly attempt the coding -- I'm still in the command line world )

[sub]

Yes, this sound like an interesting approach and probably justifies some further analysis.