[ashlar]

I'm in the process of archiving the few HD-DVD that I managed to buy before the format died.

I use AnyDVD HD to decrypt them and then feed them to eac3to to separate the various streams. I merge the streams I decide to choose through mkvmergeGUI (2.2.0 version).

The problem comes with VC-1 streams, it appears that DVDplayer is really bad at decoding them. I have the Planet Earth boxed set and even relatively simple scenes put my CPU (C2D 3.0 GHz) at 95% use. This translates into very frequent "stuttering" of the video (even though frames don't seem to be dropped, looking at the OSD).

I thought the problem could be the mkv container and tried muxing streams into an .m2ts container with tsMuxeR. Same results.

Now... my CPU decodes the killa sample with no problem, no frames dropped, no stutter... is VC-1 decoding so bad in FFMPEG?

[ashlar]

Here's the result from mkvinfoGUI: http://xbmc.pastebin.com/f339c1d36 in case it could help.

[ashlar]

Additional (strange) info.

I've tried once more and this time brought up the Task Manager, to check CPU usage...

Now I link here a photograph that I took with both the OSD on and Task Manager. This is just demuxed HD-DVD content, remuxed to .mkv. It's Episode 3 from Planet Earth (not the same sequence used for the killa sample, that comes from Episode 1).



You can see that for the video portion xbmc claims 93% CPU usage, while right beneath it mentions 55.4% which is in line with what Task Manager shows. In this case framerate is shown as not too far off (although the scene in reality was showing some stuttering, but notice that the frame drops are still the ones due to file opening).

Now here's a similar picture of just a few moments before:



In this case video mentions taking 98% CPU (while still around 54% in Task Manager), but you can see the framerate at 20.79fps, which is more in line with the heavy stuttering I was experiencing. Still no frames lost, but how can that be at 20.79fps for a 23.976fps video?

[spiff]

unless mistaken vc-1 use variable framerate like other wmv codecs

[althekiller]

I think the 99% is thread usage, so is only relative to one core. The 53% is then relative to the whole CPU package. The numbers make sense then anyway.

You're looking at the wrong numbers anyway. The aq is nearly empty in the video that stutters. We sync to audio, there's no audio, we lose sync. Decoding 1080p VC-1 in a single thread is a pretty tough task, the fact that the video decode thread has its core tapped shows that your system isn't up to the task.

I don't know much about VC-1 so I couldn't begin to recommend changes to your encoding that would help your case.

[ashlar]

unless mistaken vc-1 use variable framerate like other wmv codecs

Variable framerate or variable bitrate? The former would not make sense for this kind of content, just anime use it sometimes.

althekiller, do you mean VC-1 decoding is not multithreaded as H.264 is? If that were the case, the answer would be clear. This is a C2D at 3.0GHz... I don't know what if anything could decode in a single thread...

I'd really hate to recompress, considering this is a backup of something I legitimately own (plus, tons of time needed for that). I'll probably resort to the external player option once the "per extension" thing gets going. I could remux all VC-1 content to a m2ts content and have external player just for that.

Edit: http://lists.mplayerhq.hu/pipermail/mpla...59875.html it appears that in January ffmpeg still was decoding VC-1 in a single thread... damn!

[neurosis13]

i use kmplayer + coreavc as the external player......
as i couldnt take it anymore.
:-)
the results are ok.
i hope to get it tweaked some more but this is the way to go at the moment.

[spiff]

pretty much all video encoding use vbr, so that was definitely not what i meant when i wrote 'variable framerate'

[ashlar]

i use kmplayer + coreavc as the external player......
as i couldnt take it anymore.
:-)
the results are ok.
i hope to get it tweaked some more but this is the way to go at the moment.

With xbmc internal player and a fast cpu you get good results with all h264 content. CoreAVC is not needed for me. But with Vc1 decoding being single threaded I'll need direct show filters for it.

[ashlar]

pretty much all video encoding use vbr, so that was definitely not what i meant when i wrote 'variable framerate'

What did you mean, then? Help me understand.