Slashdot Mirror

Any idea why they never did that with H.264?

They did. See the table at the end of the H.264 features section on the Wikipedia page for the profiles that support it. And here's a paper on using 10-bit color H.264 for broadcast applications.

Higher encoded bit depths can actually lower file size at a given quality or increase quality at a given filesize regardless if you are outputting at a lower depth.

http://x264.nl/x264/10bit_02-a...
TLDR: Even though the dit depth is higher, it allows for more of the junk information to be thrown out while keeping more of the important data.

Blocking and banding are very problematic in JPEG and the easiest way to fix it is to just raise the bit depth which is probably why they added 12bit to JPEG 9.1 earlier this year.

If your laptop is having issues playing high-bitrate 1080-60p videos, then you might want to re-examine your disks IO rates and throughput consistency. It's likely that the bitrate is higher than what your drive can deliver, possibly because the drive is heavily fragmented and latency has increased. It's also possible that your laptop is severely clocking down your FSB, which would also potentially introduce problems. Almost any Dual-Core computer from the last 6 years could easily handle a 1080-60p video with a 30-40mbps stream with ease, and I'm being generously high on that bitrate number.

On the subject of PS3 playback, I cannot accept it as a legitimate decoding platform until it NATIVELY supports h.264 Hi10p and the Matroska video container. Why? Matroska has the highest level of flexibility and the widest support for not just video and audio codecs, but also integrated SSA and the highly-superior ASS format subtitle support. h.264 Hi10p not only expands the color depth, decreasing banding and increasing quality, but also produces a smaller file at the same bitrate compared to it's 8bit counter-part. In case this seems impossible, the increased depth improves the results for motion vector and qpel search, increases the quality of DCT's, and matches the CABAC encoder algorithm in such a way that the final losslessly compressed file is smaller. Since half of the current non-commercial video content is delivered in this way, it's kinda important.

http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf

Also, the PS3 Media Server should not be considered in this discussion, as the video is decoded and rendered on the hostPC and the output is streamed to the PS3.

It's not the colour space that is enhanced, but picture precision.

In general, going from high profile to hi10p (high profile 10 bit precision) allows you to compress a bit more while getting the same quality. Anime folks like it because it lets then shave around 10-20% of their not-so-small 720p and 1080p filesizes. Problem is that decoding hi10p takes more calculating power and there's not hardware decoding support for hi10p worth talking about while the typically used high profile (which uses 8 bit precision) is supported pretty much everywhere.

It absolutely does not let you compress more with the same quality.
If you have an output range of 10 bits and a source with a range of 8 bits, you're only ever going get 8 bits worth of useful information out at the end.

The only places using 10 bits (over 8) matters are:
When your source has a range > 8 bits.
During the quantization (or filtering) process to prevent the buildup of rounding/sampling errors.

The final output only ever needs a range equal to that of the source. Anything more is useless. If your final output is using 10 bit precision for an 8 bit source it just means you can quantize the same number of times and get a larger file with the same quality (perhaps imperceptibly better quality due to the lack of rounding errors, IF the user has a 10 bit display and path). Or you can quantize more and get the same file size at the same quality. Either way you get a huge bump in complexity for encoding and decoding.

Anime folks like it because they like to use the most complicated crap possible. Anime is ridiculously conducive to compression (once you properly deinterlace and IVTC it, have fun with that). You can get away with relatively low bitrates for anime. The same goes for most pure CG movies like your Kung Fu Pandas and your Toy Storys.

You can read the (shitty) explanation here: http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf
It's 10 bit processing that is better, not 10 bit storage. It's the same reason TVs, projectors, etc. have advertised 10 bit, 11 bit, etc. processing filters.
You absolutely do NOT need to output to a 10 bit file at the end.

x264 should offer 10 bit processing along with a final 10 bit to 8 bit scaling step. You'd get the benefit of not having the errors build up during compression, and you'd have all of the compatibility for hardware decoding. Professional encoders do exactly this.

I didn't mean color space as in Y'CbCr, I meant potential color range. I avoided the word depth because I wanted to distinguish between the depth of the original source (8bpc) and the possible depth of the final stream (10bpc) and the precision of the compression operations.

I agree that speed is important, but if you want the best quality at a certain encoding speed everything speaks for ditching DivX and XviD in favor of x264 as an encoder. Neither DivXs nor XviDs threading scales well when encoding on a multi-core processor. The speed gain for more than two cores is very low and going from one to two cores only nets you about 70% speed gain to begin with. When you compare that to x264 which can use all cores to 90+% of their potential thats pretty abysmal. If you search Doom9 you'll find a comparison done years ago that showed that even on single core processors when x264 settings were tuned to match XviDs speed with various settings x264 always came up on top quality wise. Unfortunately the graphs aren't there anymore and the x264 command-line arguments have changed in the meantime, but since the preset system has been added finding a good speed to quality trade off is easy. That was before several features that improve the visual quality with minimal speed loss, like adaptive quantization and the new MB-tree rate-control, were implemented. The x264 developers are constantly working to improve encoding speed as well. Take a look at the changelog.

Japanese amateur (doujin) artists have been self-publishing professional-quality albums for years now. No RIAA, no middlemen: they set up a booth at a convention and sell it. And then, afterwards, they sell extra copies from their website. It seems to work well enough: some single fandoms have produced hundreds if not thousands of albums.

Isn't it amazing what you can do when you prioritize actually making music over trying to get rich?

And don't think that the Japanese have it easier with regard to music copyright enforcement: the problem is actually so great there that file-traders have been forced to use anonymous P2P systems like Share and Winny.

PSNR not only does "not measure perceived quality", it's also of next to zero worth in determining the effectiveness of a codec. For one, x264's psychovisual optimizations actually drop the PSNR and SSIM of the output compared to a non-psychovisually optimized encode. For an example of how meaningless PSNR is, look at

http://mirror05.x264.nl/Dark/x264vsElecard/

Of worth noting is that in these screenshots, Elecard has a higher PSNR than x264.

or that you think H.264 provides a minimal quality improvement.

http://mirror05.x264.nl/Dark/website/compare.html

It does indeed.

See 300.

The Xvid rip is much more faithful to the original than any of the H.264 rips. ALL the H.264 encoders are simply heavily blurring the picture, so you lose substantial detail. If you want that, you can do that before your Xvid encodes and get the same "feature".

And I'm not a fan of Xvid, it's actually pretty over-hyped (but less so than H.264 these days). Libavcodec's MPEG-4 encoder is much, much better.

An entire series of rather graphically and musically impressive shooters--all made by a single programmer in his spare time. They're a hell of a lot of fun to play, and their difficult ranges from mildly challenging to rather crazy to utterly nightmarish.

An entire series of rather graphically and musically impressive shooters--all made by a single programmer in his spare time. They're a hell of a lot of fun to play, and their difficult ranges from mildly challenging to rather crazy to utterly nightmarish.

An entire series of rather graphically and musically impressive shooters--all made by a single programmer in his spare time. They're a hell of a lot of fun to play, and their difficult ranges from mildly challenging to rather crazy to utterly nightmarish.

Yes it does support both, and a very current beta on http://x264.nl/ touts that it has improved speed "13-10-06: ffdshow tryout revision 382 (clsid) added, faster H.264 decoding." You can also get a very nice H.264 opensource codec and an encoding GUI there, very high quailty stuff. The Encoding GUI: http://mewiki.project357.com/wiki/Main_Page/

I don't agree with some of them. XviD? Yeah, it's okay, but vastly inferior to x264. phpBB? Yeah, not bad software, but not as good as SMF.

For that matter, they also could've used H.264. In my experience, it's much superior to XviD and DivX in terms of quality.

That would be you being useless, not the codec. VLC supports it just fine, unsurprisingly, since they're involved in its development; as should any other decent media player, once you install codecs from http://x264.nl/ or one of dozens of other repositories on the web. I still haven't seen a single person fail to get it working on windows, osx or any distribution of gnu/linux.

L

then look at how the open source codec X264 has progressed in a very short period of time. Unlike DivX6 or XviD (both MPEG4 ASP), it is MPEG4 AVC. The latest build (build 263) features High profile (partial), RDO, Multi-threading Decoding is done via either ffdshow & Haali's Matroska Splitter or via mplayer. X264 is IMO absolutely brilliant and right on the heels of Nero AVC. Check it out! http://x264.nl/