SD bigger than HD?

[heronstalker]

Normally I download all of Revision3's content in large Xvid and I found it peculiar that this week's episode of Tekzilla is actually a bigger file than the QuickTime HD version. WTF?! Is there any reason why a 640 X 480 file would have a higher bit rate than a 1280 X 720 HD version of the same show? I understand that h.264 can be a more space efficient codec that Xvid, but there is no way you're going to be able to pull better quality when you have twice the number of pixels to work with at an average bit rate of 1650 kbps. This week's Xvid release of Tekzilla clocks in at 2788 kbps using QuickTime get info property sheet. Could this be a prelude for higher bit rate QuickTime HD files in the future? Personally I love the extra massage given on this week's Xvid file - you can really see a reduction in macroblocking and smoothness in motion compared to the standard Xvid releases that normally come in at around 1350 kbps. The reason why I don't download the so called High Definition video is because in it's present form it's almost unwatchable. It's a joke to call any of Revision3's content HD when you're dealing with a bitrate of 1600 or 1700 kbps. Would anyone really be happy if you had a Blu-Ray player playing back content on a 42" set at less than 2 mbps? I really hope this is just a test run for 4 - 5 mbps QuickTime HD content in the future and Tekzilla would be a good show for it to debut on.

[snizzsnuzzlr]

I download all of Revision3's content in large Xvid and I found it peculiar that this week's episode of Tekzilla is actually a bigger file than the QuickTime HD version. WTF?!

Show released 2008-07-26 was a bad Xvid encode. There were a lot of segments requirig high bitrate or CPU intensive encoding. Someone flipped the encode as normal switch not realizing the E3 (gaming video) coverage and the many seconds of scrolling text for a couple of spots require special attention. It was bad enough for me to turn off the TV, delete the file, and come over to the PC to post a comment.

Not glad there was a problem, but relieved to find I'm not the only one to see it.

[bmwt]

the "change" wasnt intentional so much as it was mencoder crashing during the second pass. The resulting file was complete enough to trick our encoding workflow into thinking it was legitimately done/ready. (the second pass *removes* un-needed bits from an xvid encode, to make it smaller)

I'll see if we cant get a fixed copy up shortly.

-b

[burkhartmj]

After seeing this thread, i compared the xvid to h.264, and the h.264 was indeed still better looking. The mencoder crash makes sense, thanks for the update.