Commercial Advance Beta Release

[mikesm]

Let me say thanks to both of you for your contributions in this area. This is a key differentiator in the DVR field, and both Myth and Sage get a lot of differentiation from these efforts.

Thanks especially for making the comskip code linux compatible. It's so much more efficent to run it on the file store instead of the backend over the network.

Thanks,
Mike

[Captain_Murdoch]

Subject goes doubly for me.

Originally Posted by Jere_Jones

Hmmm... it would seem that I am guilty of a common crime - assumption. Having not looked at the source code for MythTV's commercial detection, I assumed that comskip was the source of the "ideas" if not the code.

My sincerest apologies. I was responding (before I did any research) because I didn't like the inference that all I have done is copy code from MythTV.

And I was replying at 2am in the morning and thought I was reading that the opposite was happening. To try to set the record straight, I'm impressed by the advancements you've made. Practically the day I started using Myth two and a half years ago, I started working on the commercial detection code in it. It started out as about 133 lines of code to do straight blank-frame detection and then checked for blank-frames a certain distance apart and if they were 15,20,30, or 60 seconds apart it would assume they were a commercial. Very basic... (and wrong a lot of times) Over the couple years I've enhanced the detection with my own ideas and some learned from other's documentation out on the web, and at least once a month (and more frequently for a while after each release) people have offered more suggestions on how to do detection. I even get people suggesting collaborative detection or that I should somehow make a way to share the detection info so multiple people can benefit after one person flags a show. 5-10 people over that time have started working on patches to enhance the flagging and most have given up after a few weeks because they always have ended up making detection worse since it's not an exact science, more of an art. I'm impressed by how far you've gotten in such a relatively short while. You've implemented things that have been on my TODO list for literally years but that I haven't had the time to implement or haven't implemented just because what I had was working so well for me at the time. Lately detection had gotten worse because of things like the networks showing their logo during blank frames so the software wasn't picking up blanks as blank, so I've been spending more time on improvements over the past 3-4 months than I had over the previous 6.

Originally Posted by Jere_Jones

This is very true of the original comskip code, but I have rewritten or discarded (the PNG scanning sequence comes to mind) almost all of it. So I feel a little protective of my code, as do you.

I noticed you got rid of that part. I did too a while back. The png-style scanning was about the 2nd or 3rd way I rewrote the blank-frame detection in an attempt to speed up the detection process. Because lots of Myth users are now recording HDTV (myself included), I have modified my code again to try to keep the flagging speed consistent no matter what the resolution of the video. On higher-res video, it doesn't scan as many pixels in a frame. As the res gets higher, the spacing between pixels checked gets higher. It isn't a smooth formula, but does have 4-5 steps to help make it so that flagging a 1-hour HDTV show doesn't take 1-2 hours.

Originally Posted by Jere_Jones

I took this as a form of the "intelligent black threshold" that I added a long time ago.

Myth is used by people around the world and I've been told by users before that some places don't have black-frames around commercials, they have white, or green, or some other color. The new blank-frame detection tries to detect truly blank frames and not just black frames.

In Myth, I don't want to have to have the user tune some config file and since the tolerances will vary from station to station and potentially show to show, I have tried to keep the code where it would work reliably across a wide base of users. In the beginning, we tossed around the idea of letting users tune certain values, but I don't have the time or the patience to deal with people who don't understand the code enough to realize why certain things happen when they tweak a certain threshold. This is probably the main reason that I don't have user-configurable values for thresholds and settings other than picking the type of detection to be used.

Originally Posted by Jere_Jones

Border size has been customizable almost from the beginning.

Has been too in Myth (but don't tell the users that). I had a hidden setting that could use to manipulate the border width but I never exposed it to the users. With input from some users recently, I decided to bump the default border up a little although I still don't let the users edit the value.

Originally Posted by Jere_Jones

This was the big one. This is the addition/change/upgrade that made me think "Hey, cool, he's using some of my ideas." As far as I could tell everyone previously did commercial detection in a linear fashion. I especially keyed off on the words "block" and "score" which are all over the my source code for this. If you didn't copy the idea for this from me, my apologies. If you did, thank you for finding one of my ideas useful.

I think I've gained some good ideas from your code, so thank you. I don't think my original idea for the blocks came from your code but do remember thinking "hey, it's not as hard as I thought to make Myth do this" after I looked at yours. I believe that some of the sample code I've downloaded from the net used something like this. When I first started writing the commercial detection in Myth, I found a couple half-finished programs out on the net but none were at the point where they were more than pipe dreams I believe. I used some ideas from those and came up with a huge list of my own with some added input from users. I'm happy that someone else is working on this in a totally separate app because it will help bring better innovation to the "art" of commercial detection.

Originally Posted by Jere_Jones

This can also be found in my code since I tried to get away from the "divisible by 5" idea.

Me adding in the 5-second and 10-second spots is something totally different actually. This was just extending the list of valid commercial lengths that were looked for (the 15,20,30,60 list mentioned above had 5 & 10 added to it).

Originally Posted by Jere_Jones

Having calmed down and given this some thought, here is my comment:

Comskip was born from MythTV's commercial detection routines and owes it's existence to that code. Comskip has since grown and morphed into it's own identity that (IMHO) is innovative in some areas.

As far as I can tell, some of the improvements to MythTV's commercial detection code have previously been incorporated into comskip. The other's are not relevant to Sage's use of comskip. If I'm missing something, please let me know.

I think I can agree with all of this. Sorry if I came off harsh in my post.

Originally Posted by Jere_Jones

Regarding the linux patch, I have been unable to get it to successfully merge with any windows patching tools, but I will patch it manually and then commit it to the sage-community website.

Jere

I generated the diff with "svn diff", but I don't know enough about subversion to know if there's a way to apply a patch/diff other than using the "patch" command I'd use under Linux/Unix.

[Fluffdaddy]

Yes.......................Thank You

[Jere_Jones]

I have some questions for y'all.

1) What is more important to you for commercial detection - speed or accuracy?

I have noticed that comskip tends to either gets it really right or really wrong. This is due to some assumptions that comskip makes about the show from the git go. I could make commercial detection avoid the "really wrong" detections, but it might have to scan the recording two, three, or even four times.

This especially makes a difference depending on the amount of padding you use. More padding = worse commercial detection.

2) Is speed worth paying for it?

I have been writting my own MPEG decoder because of my desire to release a closed source version. While learning about MPEG, I have learned that royalties must be paid on every decoder distributed. That means that I could do 1 of 2 things:

1. 1. Not include a decoder or
   2. Charge enough to cover the patent fees and my time for writing my own decoder.

Not including a decoder means using directshow to use whatever decoder(s) is(are) already on your system. Hence, it will be very slow. On my development machine (a 2.4Ghz P4M) it runs at about 80-90 frames per second. It also means no possibility of a linux version.

If I include my own decoder, then I can get the speed up and (maybe) port it to linux. For comparison, my decoder will be able to run (theoretically) at about 500 frames per second. I say theoretically because at 600 frames per second, the hard drive becomes the limitation (at least on my machine).

I appreciate the feedback.

Peace,
Jere

[owilsky]

Originally Posted by Jere_Jones

I have some questions for y'all.

1) What is more important to you for commercial detection - speed or accuracy?

For me: accuracy!

Originally Posted by Jere_Jones

I have noticed that comskip tends to either gets it really right or really wrong. This is due to some assumptions that comskip makes about the show from the git go. I could make commercial detection avoid the "really wrong" detections, but it might have to scan the recording two, three, or even four times.

This especially makes a difference depending on the amount of padding you use. More padding = worse commercial detection.

I do not have any problems if it lasts a long time when accuracy is good. Maybe there should be an option how long/accurate comskip should work? So everybody can choose himself...

Originally Posted by Jere_Jones

2) Is speed worth paying for it?

That depends on "how much" ;-)
Maybe make this also optional as a plugin: You doesn't want to pay has to wait ;-) and who purchases the plugin has to wait less ...

Thoughts?

Oliver

[snipeman]

Jere,

Put me down as another vote for accuracy. I don't even need an option. I'll let Moore's law take care of the processing time.

When I'm sitting at my TV watching a show, accuracy is all that matters. I can buy the proper processing power to deal with whatever high CPU demand code you produce.

In my setup, my HTPC does not run comskip. My media server does, once ever 6 hours with an XP schedule kicking off the VB script. My media server isn't doing anyting else CPU intensive anyway. Usually right now it processes for about an hour and a half for ever 6 hour segement of the day. If it processes for 3 hours instead of an hour and a half, it wouldn't bother me in the slightest.

I'd be happy to pay a resonable fee for the decoder license. I don't run Linux and don't plan to, so the port is of no interest to me. I'd perfer your time allocated to comskip spent on better accuracy!

Just my .02

Andy

[Crashless]

Originally Posted by Jere_Jones

Is speed worth paying for it?

If it really is the speed difference you're talking 500 vs. 90, then yes. Especially if scanning multiple times will be necessary to have really good accuracy.

How much $ are we talking here? $10-30 seems to be the sweet spot for these type of things, is that your target? If so, I'd reccomend two versions:

1. Free version, (maybe just current version) that uses a system decoder, runs at 90fps and doesn't do multiple passes.

2. Pay version, ($10-$30) your decoder, multiple passes.

I'd buy that. Especially if it can scale to HD resolutions. Then that speed difference would be absolutely necessary.

[BerrantRyke]

[QUOTE=Jere_Jones]I have some questions for y'all.

1) What is more important to you for commercial detection - speed or accuracy?

Accuracy. Am musch as I LOVE comskip, its annoying when I have to rewind.

2) Is speed worth paying for it?

I'd gladly plop down $20 or so for accuracy. Again, speed it not my concern. I have two clients that can happily chew away at the detect process. As far as linux goes... Not for me.

[RedR]

Accuracy is the most important in my book. Speed is useless if it’s not always dead on.

Possibly one idea for ya. Seeing how many folks run home LANs, perhaps a distributed computing effort for comskip detection? HA!

Anyway, thanks for keeping it going,
RedR

[ajuhawk]

I vote for accuracy as well. Time is unimportant as I'm usually watching the show a day later anyway. A linux port could be useful as I'm thinking about making my server linux and then it could do something with the spare cycles.

As far as the comment about distributed commercial detect processing, I'm currently using that - Cayars has developed a method that is in beta testing now. See here for more info on that.

[JasonJoel]

Accuracy. Accuracy. Accuracy.

And 80-90 fps is fine with me. Faster would be better (and I would pay for it), but I could live with 80-90 fps no problem.

Jason Bottjen

[justme]

I'd like both thank you. But if I have to choose accuracy.

Still if you can deliver 500fps(I'd be happy with anything over 360fps on a P4 2.4 GHz CPU) I would pay for speed too. One stipulation is that I'm a big fan of trialware. I'd prefer/love it, if you could somehow allow a speed limited(1/3 ?) 14 day trial version. Maybe even strip out your mpeg decoder for the trial, for legal reasons. It's not that I doubt you're work, Comskip's current gen. has proved it's value. I'd just like to be able to see how much more accuracy I'll be able to get with a new pay version.

As for price I know I'd pay 10-15$ for the speed you quote at comskip's current accuracy. So any more than that would be dependant on the accuracy factor, but to be honest, I think 20$ would be fair. If it cost 25$, or more, I'd absolutely need a trial to even begin to consider paying. Just my honest opinion. I know you don't want to spend your time developing an app, only to have people not want to pay what they said they would. So we should all tryto keep our responses about price honest. I'm pretty sure that's what he's after.

BTW Linux is a nonissue for me, as of now.

/justme

[Blue]

Originally Posted by Jere_Jones

1) What is more important to you for commercial detection - speed or accuracy?
2) Is speed worth paying for it?

I'll jump on the bandwagon and also say accuracy. We really don't start watching recordings until at least the day after, so comskip just needs to finish within 24 hours. However, why not offer both solutions as an option?

I'm sure if you build it, the funds will come.

[White94Cobra]

I'll vote for accuracy. I'd gladly pay ~$20 to speed it up though.

[Crashless]

Originally Posted by Jere_Jones

I have noticed that comskip tends to either gets it really right or really wrong. This is due to some assumptions that comskip makes about the show from the git go. I could make commercial detection avoid the "really wrong" detections, but it might have to scan the recording two, three, or even four times.

It's the scanning "two, three, or even four times" that makes me think the two points are intertwined.

[doncote0]

Hi Jere Jones,

How do configure to have comskip autodelete those log files? They are still around when comskip finishes.

Thank You

[Jere_Jones]

Originally Posted by doncote0

Hi Jere Jones,

How do configure to have comskip autodelete those log files? They are still around when comskip finishes.

Thank You

Comskip won't delete the log files. The best option to prevent them from being generated by setting verbose=0 in the ini file.

Jere

[doncote0]

Works for me. Thanks, Jere. That was quick!

[Cazador]

What i woudl recomend would be to have an option to do either the high speed, or the multiple runs at high speed.

[krutaw]

Originally Posted by Jere_Jones

I have some questions for y'all.

1) What is more important to you for commercial detection - speed or accuracy?

I have noticed that comskip tends to either gets it really right or really wrong. This is due to some assumptions that comskip makes about the show from the git go. I could make commercial detection avoid the "really wrong" detections, but it might have to scan the recording two, three, or even four times.

This especially makes a difference depending on the amount of padding you use. More padding = worse commercial detection.

2) Is speed worth paying for it?

I have been writting my own MPEG decoder because of my desire to release a closed source version. While learning about MPEG, I have learned that royalties must be paid on every decoder distributed. That means that I could do 1 of 2 things:

1. 1. Not include a decoder or
   2. Charge enough to cover the patent fees and my time for writing my own decoder.

Not including a decoder means using directshow to use whatever decoder(s) is(are) already on your system. Hence, it will be very slow. On my development machine (a 2.4Ghz P4M) it runs at about 80-90 frames per second. It also means no possibility of a linux version.

If I include my own decoder, then I can get the speed up and (maybe) port it to linux. For comparison, my decoder will be able to run (theoretically) at about 500 frames per second. I say theoretically because at 600 frames per second, the hard drive becomes the limitation (at least on my machine).

I appreciate the feedback.

Peace,
Jere

Jere ~

Just my 2cents here...

I'd prefer to have accuracy over speed. I'd also be more than willing to pay for a version that was extremely accurate.