HDPVR h.264 works, but very slow and lots of errors

[loonsailor]

I'm running comskip 0.80.25 donator's version on ubuntu 9.04 using wine, processing files that were generated by SageTV. I haven't touched comskip.ini. System is an AMD X4 905e, 4GB, so plenty of horsepower.

For the .mpg files, which come from an HD-HomeRun, comskip is great and lightning fast. For the .ts files that come from my HDPVR, comskip works, but not quite as well (cuts of commercials a few seconds early). More importantly, it generates lots of errors, and goes VERY slowly. For comparison, comskip processed an episode of Without a Trace (mpeg2-ps 528x480i 29.97fps, ac3, 1.66GB) in 98 seconds, with no errors. In contrast, an episode of Mad Men recorded by the hdpvr (mpeg2-ts h.264 1080i, aac, 3.71GB) took 5366 seconds, about 1.5 hours - 60X slower! It also generated lots of errors. Here's a sample:

Code: Select all

jerry@jivo:/var/media/tv$ wine comskip -t MadMen-TheArrangements-809800-0.ts
Comskip 0.80.025, made using:
mpeg2dec-0.4.0 - by Michel Lespinasse <walken@zoy.org> and Aaron Holtzman
The commandline used was:
comskip -t MadMen-TheArrangements-809800-0.ts

Opening MadMen-TheArrangements-809800-0.ts
No INI file found in current directory.  Searching PATH...
INI file found at C:\windows\comskip.ini
Using C:\windows\comskip.ini for initiation values.
Auto selecting the PID.
[h264 @ 03332080]sps_id out of range
[h264 @ 03332080]non-existing SPS 31 referenced in buffering period
[h264 @ 03332080]B picture before any references, skipping
[h264 @ 03332080]decode_slice_header error
[h264 @ 03332080]no frame!
[h264 @ 03332080]sps_id out of range
[h264 @ 03332080]non-existing SPS 15 referenced in buffering period
[h264 @ 03332080]non-existing PPS 0 referenced
[h264 @ 03332080]decode_slice_header error
[h264 @ 03332080]no frame!
[h264 @ 03332080]sps_id out of range
[h264 @ 03332080]non-existing SPS 31 referenced in buffering period
[h264 @ 03332080]B picture before any references, skipping
[h264 @ 03332080]decode_slice_header error
[h264 @ 03332080]no frame!
...
[h264 @ 03332080]number of reference frames exceeds max (probably corrupt input), discarding one
    Last message repeated 2 times
[h264 @ 03332080]mmco: unref short failure
    Last message repeated 1 timessec (16.91 fps), 1.02 sec (16.67 fps), 3%
[h264 @ 03332080]number of reference frames exceeds max (probably corrupt input), discarding one
    Last message repeated 479 times
[h264 @ 03332080]error while decoding MB 118 0, bytestream (-3)
[h264 @ 03332080]error while decoding MB 6 6, bytestream (-4)
[h264 @ 03332080]error while decoding MB 32 2, bytestream (-3)
[h264 @ 03332080]error while decoding MB 47 2, bytestream (-3)
[h264 @ 03332080]error while decoding MB 49 0, bytestream (-4)
[h264 @ 03332080]mmco: unref short failure
[h264 @ 03332080]error while decoding MB 38 2, bytestream (-3)
[h264 @ 03332080]error while decoding MB 23 2, bytestream (-3)
[h264 @ 03332080]error while decoding MB 37 2, bytestream (-3)
[h264 @ 03332080]error while decoding MB 48 0, bytestream (-10)
[h264 @ 03332080]mmco: unref short failure
[h264 @ 03332080]error while decoding MB 37 2, bytestream (-3)
[h264 @ 03332080]error while decoding MB 40 2, bytestream (-3)
[h264 @ 03332080]mmco: unref short failure
 0:00:00 - 111266 frames in 5365.83 sec (20.74 fps), 4.62 sec (2.60 fps), 99%%
111276 frames decoded in 5366.29 seconds (20.74 fps)
Commercials were found.

There's LOTS more, but you get the idea.

So, is it normal for these h.264's to go so much slower, and throw all these errors? I know it's higher res and bigger, but only 2X the size yet it takes 60X the time to process! If that's just the way it is, OK, I guess I'll live with it. After all, it works, which is kind of magical. Is there anything I should try to improve the situation?

Thanks!

[erik]

yes its normal h.264 is MUCH slower. Not muh I can do right now but I hope to be able to add hardware supported decoding.
The error message are also normal because of limitations in the h.264 decoder and will disappear with newer version of Comskip

[loonsailor]

OK. Thanks for the prompt reply. I'll look forward to improvement in this area, but in the mean time I'm very grateful for the product as it is.