Originally Posted by rdjam
It's got 58% more bit budget than the VC1 version. You have no idea how efficiently or inefficiently it uses this extra data rate. But it has 58% more data - that's all there is to it.
...and it was 58% well spent. This is a good
thing. It captured things the vc-1 encode missed. The vc-1 approach may be good for dig-cable/sat/ip applications, but is just plain unnecessary for optical disc applications (where space is there for the taking). Case closed.
"marginally"?? Where have you been. The Mpeg encodes in these comparisons have been LOADED with huge macroblocking and artifacting in almost every scene. They were nowhere close to the same league as the VC1 ecodes, for the most part - unlike this AVC comparison, the Mpeg encodes were filled with visible artifacts.
...and they also were shorted on program size by factors as far as 0.54x and bitrates well under 20 Mb/s. Did this very relevant detail slip by you, again? That is a pretty different situation than the avc encode we have here, today. This should tell you it is primarily a matter of codec implementation,
rather than the identity of the codec, itself. Had the mpeg-2 encodes run into the 30 GB and 30 Mb/s range, it too, may have fared quite favorably, if not better, than the vc-1 encode.
Similarly, had the vc-1 encode been halved in program size, you would be complaining about the implementation
of the codec giving the results you see, rather than the fault of the codec, itself. Once again, your points are debunked. Each of these cases had very little to do with the codec, but rather, how they were used. Each time, bitrate
ends up being the overwhelmingly dominant factor. Even you
have remarked that vc-1 is not immune to a shortage of it.