comskip vs SA - results

[bialio]

Running the latest versions of both, I decided to see which is most accurate at the moment. The output below is from the .edl files generated by comskip 0.80.008 and SA Version 1.0.19.604.

On an episode of Bones (HD 720p, mpg from FOX) here are the results:

comskip

5.00         133.52	0
609.43       750.20	0
1259.74     1471.85	0
2019.88     2235.92	0
2677.96     2910.22	0
3154.20     3307.19	0
3734.81     3771.55	0
3839.20     3839.22	0

SA

0.00300833     137.565	0
604.587        754.554	0
1254.72       1475.37	0
2014.78       2179.77	0
2193.11       2239.83	0
2677.89       2913.31	0
3148.65       3310.6	0
3729.71       3769.7	0
3837.97       3837.97	0

I've got COMSKIP set for 5 seconds padding. So as you can tell, the results are almost identical. ShowAnalyzer had 1 false positive (2179.x to 2193.x marked incorrectly as part of the show). So for mpeg it's pretty much a draw as far as I am concerned.

For h.264 HD programming, the tale isn't as pretty.

This is a 1080i recording of Stargate Atlantas, from HD-PVR.

comskip:

    5.00     2.90	0
 259.33    374.34	0
1071.50   1121.45	0
1728.09   1806.81	0
2364.93   2538.17	0
3135.80   3185.95	0
3565.96   3597.46	0

SA:

2.44643    7.6303 0
204.315   403.169 0
6670.72   6670.72 0

Quite clearly comskip did better on the H264 - but it took forever. It seemed like it was processing about 25 frames / sec (while mpeg2 galloped along at about 325 frames / sec).

This was running on a C2D based machine (E4300) overclocked up to 2.6 GHz.

So for now I think I'll let comskip take care of my commercial processing - Jere has said that the detection "sucks" in SA currently, so I'm sure he's working on fixing it. I think erik knows comskip is slow also. So that's the state of things as I see them now.....

btl.

[Djc208]

Originally Posted by bialio

Quite clearly comskip did better on the H264 - but it took forever. It seemed like it was processing about 25 frames / sec (while mpeg2 galloped along at about 325 frames / sec).

This was running on a C2D based machine (E4300) overclocked up to 2.6 GHz.

And 80.008 has a 2x speed increase for h.264! I haven't timed mine but I know it took days of running to get through all my h.264 recordings (maybe 12~15) on top of the MPEG stuff that was being recorded. Shows how brutal h.264 is. Glad to see I'm good staying where I'm at though. Thanks for the info.

I'd love to see this stuff get moved to GPU computing but we're a long way off from that.

[stanger89]

Originally Posted by bialio

...but it took forever. It seemed like it was processing about 25 frames / sec (while mpeg2 galloped along at about 325 frames / sec).

This was running on a C2D based machine (E4300) overclocked up to 2.6 GHz.

So for now I think I'll let comskip take care of my commercial processing - Jere has said that the detection "sucks" in SA currently, so I'm sure he's working on fixing it. I think erik knows comskip is slow also. So that's the state of things as I see them now.....

btl.

Yeah it is quite slow, but I think I saw a comment from Erik about working on a '5x' improvement in processing speed coming.

Originally Posted by Djc208

I'd love to see this stuff get moved to GPU computing but we're a long way off from that.

Yeah, I've got mixed feelings on that. It sounds great at first, but then again, if you run comskip on the server (ideally) why would you put a good/expensive GPU in it?

I do have an overall hint for those of you who are using the H.264 processors. First off, cudos to Jere for his great Dirmon2.

The problem is, as noted, h.264 detection takes forever, as such it was monopolizing all my processing time and causing my "quick" mpeg-2 recordings to never get processed, due to a backlog of H.264 recoridings. So my solution was this:

• Create 2 Jobs, one for H.264 and one for MPEG-2, this is really quite easy for HD PVR users as the HD PVR recordings are ts, and everything else is mpg.
• Set the H.264 Job to require "51 resources" this effectively prevents two H.264 jobs from running at a time (or for the more general case you set it to 100/n+1, where n is the number of cores)
• Set the MPEG-2 job to "49 resources" (or 100/n-1), this allows two MPEG-2 jobs to run at a time, but also allows an MPEG-2 job to be run if an H.264 job is running.
• Since H.264 takes so long to process I changed the process priority to -1 so it processes the MPEG-2 first and oldest H.264 last.

[Djc208]

Originally Posted by stanger89

Yeah, I've got mixed feelings on that. It sounds great at first, but then again, if you run comskip on the server (ideally) why would you put a good/expensive GPU in it?

I wouldn't put an expensive one in it but if the kind of speed improvements they keep talking about were real it might justify a lower end part. More realistically it would give me someplace to put my older card when I upgrade my existing GPU.

In many cases it could be cheaper than a quad core CPU and is about the only thing on my server that causes high useage. But if better code can do the same thing than it's a moot point.

[stanger89]

Originally Posted by Djc208

I wouldn't put an expensive one in it but if the kind of speed improvements they keep talking about were real it might justify a lower end part.

Yeah, the numbers just always seem disappointing on all but the highest-end cards.

More realistically it would give me someplace to put my older card when I upgrade my existing GPU.

Well there's always that

[ghostlobster]

I was debating which direction to go with commercial skipping for h.264. I had already paid for an SA license, but Jere was MIA, so I was really leaning towards Comskip. Well, I saw Jere come back about a week ago, so I figured I'd give SA Suite a shot, and actually, I've been pretty happy with it. OK, it's not perfect, but it's very good. I completely disagree with Jere's post when he said that commercial detection sucked. I've been happy!
The speed is just fine as well. It's nearly "real-time" in that a 1 hour program takes about an hour to process.
I really like the way that SA is shaping up for h.264. I'm sure that comskip is right on as well, but I have not tinkered with it for h.264 at all.

[stanger89]

Anybody figure out how to get the new SA to not install/run the whole "suite". I tried it a few times but I don't want to replace Dirmon.

[briands]

Originally Posted by stanger89

Anybody figure out how to get the new SA to not install/run the whole "suite". I tried it a few times but I don't want to replace Dirmon.

Just install it then set up your dirmon process to run ShowanalyzerENGINE.exe instead of showanalyzer.exe

[stanger89]

See, and I thougth showanalyzerengine.exe was the new gui/scanner/deally.

[appelm]

Originally Posted by stanger89

The problem is, as noted, h.264 detection takes forever, as such it was monopolizing all my processing time and causing my "quick" mpeg-2 recordings to never get processed, due to a backlog of H.264 recoridings. So my solution was this:

• Create 2 Jobs, one for H.264 and one for MPEG-2, this is really quite easy for HD PVR users as the HD PVR recordings are ts, and everything else is mpg.
• Set the H.264 Job to require "51 resources" this effectively prevents two H.264 jobs from running at a time (or for the more general case you set it to 100/n+1, where n is the number of cores)
• Set the MPEG-2 job to "49 resources" (or 100/n-1), this allows two MPEG-2 jobs to run at a time, but also allows an MPEG-2 job to be run if an H.264 job is running.
• Since H.264 takes so long to process I changed the process priority to -1 so it processes the MPEG-2 first and oldest H.264 last.

Are you using comskip monitor or something else?

[bialio]

related question, how do you set the process priority? I see some "queue" priority stuff in Dirmon2 for each job, but I can't find any documentation that says how it works....

btl.

[stanger89]

Originally Posted by appelm

Are you using comskip monitor or something else?

Dirmon2

I think it always starts the "processor" at low or idle priority.

[bialio]

Since H.264 takes so long to process I changed the process priority to -1 so it processes the MPEG-2 first and oldest H.264 last.

That's the part I'm not sure how you accomplished.

[stanger89]

Oh, I think I just set Queue Priority Boost/This Job to -1 for the H.264 job. Actually I think I might have set Older Targets to -1, I can't remember which for now.