Quote:
Originally Posted by Karnot
You obviously lie.
|
Now, now. With CoreAVC even my little 1.6 GHz Pentium M laptop can decode LuPerry's 1280x720 Sumomomo Momomo with ease, averaging at 70-80% CPU.
Gunboat Diplomacy: Most of your comments have one weakness: Amost all groups I know which offer a "big" h.264 encode _also_ offer a smaller XviD compatibility encode at the same time. And those groups who use h.264 exclusively tend to release small in the first place. So, people who for some reason prioritize "small" over "better quality" are not left out in the cold.
Also, with all due respect, just 1-2 screenshots will not prove or even just indicate anything whether or not the higher bitrate will be justified. Higher bitrate enables the encoder to filter the frames differently - sharper, less smoothing, more details. This is what's often misunderstood by non-encoders, the codec alone doesn't make the major difference (though it accentuates it), the bitrate enables the _encoder_ to create something better.
Now it's fine if YOU for YOURSELF decide that the differences are too small to warrant the big download. In this case, get the smaller encodes. However, there are a significant number of people (in my experience at least 10% of the fans and growing) who disagree with you and insist on the bigger releases. Ask yourself, would it be right for you (whose priorities have been met before) to request that these people get screwed over?
Quote:
|
Originally Posted by bayoab
Also, in general, despite what some posters seem to think, there is no corrolation between increased size and increased quality.
|
Dang, all those codec developments and optimizations to save bits and bitrate in the past years have all been in vain
... bayoab, please leave the technical talk to people who actually have any knowledge about this issue. This ignorant statement disqualifies you from any meaningful discussion on this subject.
The constant quant issue: Here, I repeat what was discussed indepth in the main thread about h.246. I want to dissuade people from using constant quant or constant quality, because the produced result is _always_ inferior to a proper multipass encode. Therefore, if you insist on preserving a "constant quality", make a CQ-encode to determine the right filesize, and THEN multipass on it - that way you at least don't lose quality unnecessarily.