VC1 encoding speed - Is this right?

[Dark Eiri]

Hey guys.
I'm trying to encode a 720p video to VC-1, getting ~20fps 1st pass and ~3.5fps 2nd pass, on a Q6600. Is this right?
It's almost a third of the speed I can get with x264 almost maxed out. OK, unfair, x264 is insanely optimized, but still, it should be at least faster than this, right?!
I'm using TMPGEnc Xpress 4, I tried Nic's encoder but it's about the same speed. Enabling CUDA on TMPGEnc actually slows it down to ~15fps 1stpass and ~3fps 2ndpass (and it shows 1% CPU and 99% CUDA usage, but my CPU is 99% loaded, so I guess it's just marketing).

[Dark Shikari]

Don't both encoders use the same Microsoft encoding library?

You could try the Expression Encoder 2; there's a free trial, and it uses the latest VC-1 SDK, which supposedly is a good bit faster.

But get used to the speed: Microsoft's VC-1 encoders are shockingly slow as a general rule, far slower than one would think they should be, especially considering that they have loads of assembly optimization too.

[Dark Eiri]

Thanks for your help! I'll try the Expression Encoder.
If it doesn't work, I'll stick with x264. Even though the Xbox360 supports Stereo AAC only, at least the video quality will be marginally better!

EDIT:
Just tried the Expression Encoder and I have to say this: ultimate improvement! I'm getting ~20fps 1st pass and ~8fps 2nd pass, plus, much (believe me, MUCH) better quality than TMPGEnc was delivering.

Finally I'll be able to use 5.1 audio on the 360.
Still, I'll stick to x264 for videos with stereo sound, it's still better than VC-1, even limited by the Xbox360 compliant settings.

[benwaggoner]

Thanks for your help! I'll try the Just tried the Expression Encoder and I have to say this: ultimate improvement! I'm getting ~20fps 1st pass and ~8fps 2nd pass, plus, much (believe me, MUCH) better quality than TMPGEnc was delivering.
Huh. Perhaps they're not using the VC-1 Encoder SDK yet?

Finally I'll be able to use 5.1 audio on the 360.
Still, I'll stick to x264 for videos with stereo sound, it's still better than VC-1, even limited by the Xbox360 compliant settings.
Unless you're using really aggressive bitrates and encoding modes, you really shouldn't be seeing that big a difference between VC-1 and H.264.

[Dark Shikari]

Unless you're using really aggressive bitrates and encoding modes, you really shouldn't be seeing that big a difference between VC-1 and H.264.Good thing there's no comparison between H.264 and VC-1, but rather between x264 and the VC-1 Encoder SDK ;)

[Dark Eiri]

Huh. Perhaps they're not using the VC-1 Encoder SDK yet?


Unless you're using really aggressive bitrates and encoding modes, you really shouldn't be seeing that big a difference between VC-1 and H.264.

The backgrounds in VC1 videos are slightly blockier than x264 (VC1 inloop filter enabled, don't know if the 360 respects that, but it's about the same output quality I get on WMP11) and really small details are better on x264 too. VC1 isn't bad at all, but x264 seems to compress a little better with the bitrates I'm using (~5 Mbps for 720p30 / ~8 Mbps for 720p60).

Just for the record, I'm not encoding movies, only live music performances from HDTV. Those are not as easy to compress as movies, since there's A LOT of movement, lights flashing and cameras in motion most of the time. I'm sure in movies the difference would be almost impossible to spot.

[benwaggoner]

Just for the record, I'm not encoding movies, only live music performances from HDTV. Those are not as easy to compress as movies, since there's A LOT of movement, lights flashing and cameras in motion most of the time. I'm sure in movies the difference would be almost impossible to spot.
What encoding mode are you using? To get flash/strobe compensation, you should be using 2-pass VBR or 1-pass CBR with Lookahead Rate Control.

[LoRd_MuldeR]

VC1 inloop filter enabled, don't know if the 360 respects that, but it's about the same output quality I get on WMP11

The entire point about inloop deblocking is that it works "in loop" and not as an optional post-processor.

Hence it can't be disabled at playback time, if it was enabled at encoding time - and vice versa. Every decoder has to respect it.

Skipping the inloop deblocking would cause corrupted output (and I don't mean blocking) ...

[Dark Eiri]

What encoding mode are you using? To get flash/strobe compensation, you should be using 2-pass VBR or 1-pass CBR with Lookahead Rate Control.

2-pass VBR with Peak Bitrate control (peak at 14 Mbps).

The entire point about inloop deblocking is that it works "in loop" and not as an optional post-processor.

Hence it can't be disabled at playback time, if it was enabled at encoding time - and vice versa. Every decoder has to respect it.

Skipping the inloop deblocking would cause corrupted output (and I don't mean blocking) ...

So it's not like the deblocking/postprocessing in H264, that can be disabled for speed. Thanks for the info!

[nurbs]

I think mulders point was that it's exactly like deblocking in AVC. If you have it on during encoding and turn it off on playback it can potentially screw up the whole picture.

[Dark Eiri]

I think he meant that if you disable the inloop filter, the frames would be completely screwed up, differently from h264 since some old GPUs didn't support deblocking via hardware decoding, so the H264 videos were all blocky, but it wasn't really ruined.

[nurbs]

That happens with avc as well, even at high bitrates. Akupenguin posted a few example pics showing that in a thread about the deblocking some time ago. IIRC the reason for that is that if you activate the deblocking during encoding the deblocked frame is used as a reference for the following frames. If you turn it of on decoding that will cause errors for every predicted block and it gets worse over time. How bad the errors are varies in different files, but it's not only blocking but other errors as well.

[Dark Shikari]

I think he meant that if you disable the inloop filter, the frames would be completely screwed up, differently from h264No, if you disable deblocking in H.264 on playback instead of encoding time, you risk exactly that.