10-Bit H.264

Source: https://gist.github.com/l4n9th4n9/4459997

For all those who haven’t heard of it already, here’s a quick rundown about the newest trend in making our encodes unplayable on even more systems: So-called high-bit-depth H.264. So, why another format, and what makes this stuff different from what you know already?

First off: What is bit depth?

In short, bit depth is the level of precision that’s available for storing color information. The encodes you’re used to have a precision of 8 bits (256 levels) per color channel. There are usually three color channels, so that makes a bit depth of 24 bits per pixel, which is also the most commonly used bit depth of modern desktop PCs. Now, you can use a higher bit depth for video encoding, and x264 currently allows up to 10 bits per channel (1024 levels and 30 bits per pixel), and of course that allows for much higher precision. But: Most graphics cards and display devices don’t allow more than 24 bits per pixel.

This makes higher bit depth sound pretty pointless, so why are we doing this? Here’s a bit of side info: Most LCD displays (TN panels to be precise) can only represent a bit depth of 6 bits per channel (a mere 64 levels). This would look pretty awful under normal circumstances, so these displays use a little trick called “dithering” to simulate a bit depth of 8 bits per channel. In simplified terms, this means that the panel’s controller quickly alternates between the nearest colors in a dynamic pattern. When done correctly, this creates the illusion of a higher color accuracy than what the panel is actually capable of displaying.

The exact same trick can be used to display high-bit-depth encodes.

But by that logic, couldn’t we just encode with 8 bits and hardcode that dithering?

Of course that’s possible, and in fact we’re already doing this to prevent so-called banding (http://en.wikipedia.org/wiki/Colour_banding). But this also has a big drawback: The bitrate required to keep the dithering intact is disproportionately high.

This brings us to the real advantage of higher bit depths: We can save bandwidth even if the source only uses 8 bits per channel.

That’s right: Not only do we no longer need to hardcode any dithering, but higher bit depth also means higher error tolerance. Losing one bit of information in an 8-bit color space is equivalent to losing three bits in a 10-bit color space, and thus the same quality can be achieved with less bitrate. Want an example? One of my first tests was encoding episode 13 of Shakugan no Shana from a DVD source, with dithering added to prevent banding. I used the exact same input and settings for both encodes.

The video track of the 8-bit encode has 275 MiB, while the 10-bit encode has no more than 152 MiB and doesn’t look worse at all – in fact, it even looks better than the much larger 8-bit encode.

Now, if I hadn’t hardcoded the dithering for the 10-bit encode and instead passed a high-bit-depth picture to x264, it would’ve resulted in even better perceived quality and an even smaller file size!

That’s terrific, but there has to be a catch to this, right? Unfortunately, yes. Software support is currently lacking in a lot of places, but it’s being worked on. Decoders that don’t support higher bit depths don’t simply fail to decode anything, but decode wrong information, which leads to really annoying artifacts: http://screenshots.srsfckn.biz/10bit-decodefail.png Note that also none of the available hardware accelerated decoders (VDPAU, DXVA, CUVID, etc.) support this.

Currently, you have the following options for playing such content:

  1. MPlayer2 (cross-platform, Windows builds at http://mplayer2.srsfckn.biz). You might want to use SMPlayer as GUI (http://smplayer.srsfckn.biz)
  2. VLC (cross-platform, use the nightly builds at http://nightlies.videolan.org/build/win32/last/). It’s not as bad as it used to be, seriously.
  3. CCCP Beta (http://www.cccp-project.net/beta/) Note that this is currently a CCCP exclusive feature, so you will not get this by simply installing the most recent ffdshow-tryouts.

And what does this all mean for my precious fagsubs?

It means that we’re doing dual encodes until compatible software is more readily available (i.e. CCCP supports it in a release build), but it also implies the following:

  1. much smaller encodes with the same or better perceived quality
  2. slightly smaller but better looking encodes
  3. same file size but much better quality, right up to transparency (http://en.wikipedia.org/wiki/Transparency_(data_compression))

So, things can only get better! I’ll keep you posted.

============================JEEB’s Rant=================================

Just a quickie on current 10bit H.264 support:

  • ffmpeg/libav have now had it for ~months (made by irock, they now have asm optimizations by Jumpyshoes)
  • mplayer(2) has had support for some time now ( these builds recommended, can be used with smplayer if you need a front-end )
  • VLC will have it in their next release ( you can test with nightlies from here )
  • Lord patched it into FFDShow-tryouts (and I undumbed its swscale usage flags so that RGB output wouldn’t look like crap). It should work fine’ish, although we are still scratching off some rough edges. Like the fact that it seems like we’ve stumbled onto a bug in VSFilter not really having as correct color conversions as possible inside. Of course, whether or not the effects of this bug are visible to people is a whole separate affair. Regardless, we’re working on it.

What is this whole “10bit” affair?

Higher-than-8bit colorspaces are part of the H.264 standard, usually until now only used in the “professional” zone. It’s not really anything new, and there actually was at least one DirectShow decoder for it available on the internet before libavcodec got one (trivia: MainConcept’s broadcast decoder). It just wasn’t picked up by the media companies for the masses, where the choice went towards Blu-ray just hitting the source with immense amounts of bitrate paired with 8bit (and thus no open source entrepreneur had yet taken it into his or her TODO list until irock developed 10bit encoding routines into x264 during last year’s GSoC program).

Unlike what would probably come to your mind first when thinking about “higher bit depth in color”, its biggest merit for most of the people is not in the capability of actually having a way to keep 10bit things 10bit (as most people pretty much have no way of getting such content originally), or in the fact that you could use hyper special rendering straight onto a 30bit display or whatever. It’s compression.

Even if your source is originally 8bit, encoding it in 10bit (in case of lossy compression, of course — otherwise the “redundant” data will actually start biting us. Although the output of course wouldn’t be identical compared to the 8bit source either in such a case, either) will have the merit of making the output suffer less from various compression artifacts. In layman’s terms, this means that lossy compression will be more efficient in leaving things pretty, leading to smaller files looking better in the end (Ateme’s PDF on this).

Not to mention that even if one converts the 10bit picture into a 8bit one to make it easier to deal with (for such stuff as playback etc.), the difference is usually miniscule (after all, we are in the same 4:2:0 colorspace), or might even look better as some ways of conversion use dithering in the process.


Thanks as well! Very good explanation! Does kind of the same apply to 12-bit transcodes? Calculating effort aside is it better to encode a x264 8-bit high-bitrate source to x265 10-bit or 12-bit; purely on grounds of subjective quality / Filesize?


This seems to be a repost of an old post but let me just say this here once again because it still makes my blood boil: DISK SPACE IS CHEAP. It is cheap now and it certainly was cheap years ago even before the hi10p fad was imposed on the entire community. The amount of pain and inconvenience this whole hi10p “decision” has brought is completely unjustified when you consider the supposed benefits. If after all this the best thing you can say for yourself is that you helped people save some space then this is not even funny: it’s just a fucking tragedy. To top it off most people won’t ever see the difference on the actual image being reproduced. So let’s see where this leaves us: people STILL can’t play their hi10p anime on their iPhones, Android phones or tablets, iPads, Apple TV, Fire TV, chromecast or any Android box. Not even the most powerful Android TV device yet (the Nvidia Shield) has a perfect hi10p playback. So essentially you still need a computer to play it. In this day and age when everybody is cord-cutting and we can consume our multimedia seamlessly on any device we STILL would need to power on our computer to watch this stuff. The icing on the cake is that if 10bit is what they needed they could easily move to x265 10bit, a standard that it’s actually being supported by almost every hardware manufacturer worth naming but then I remember that the purpose is to inconvenience the most people possible so it makes sense that they haven’t moved to that standard yet. I hope you’re all happy.


By ‘perfect playback’, what do you mean? I’m asking honestly and not jabbing you. I’m trying to gain some insight into h.265.

I’m quite the noob with h.265/HEVC but recently purchased the Shield and have been busy doing the grunt work transcoding my discs and using Plex as the server. I heard the Shield had HEVC decoding on the hardware so I’ve been experimenting to see what benefits or limitations there are, trying every encoding profile and option. On low end PCs, I can’t even view an HEVC video directly in VLC. But, those same PCs can stream it just fine thru Plex without transcoding, even at 10-bit. I’ve had numerous Android phones and Win10 PCs streaming at the same time, all with varying levels of CPU, and they can all play these videos. I have an older phone that always triggers transcoding, but the server did the heavy lifting on on that. I’m not going to try them directly, though. Copying a 12GB encoding of Avatar to a phone doesn’t make sense.

Visually, the h.265 files mostly look like the h.264. I have to use ‘mostly’ because there is one issue I can’t seem to overcome, yet. (the noob blues) The original X-Men has a lot of dimly lit scenes and they look horrible in h.265. In the end, it doesn’t make sense to throw HEVC at that one anyway just to save a GB.

I need to counter, though, about the disk space being cheap. That’s only for certain systems. If I was going the dedicated PC or NAS route, yes, it would be quite easy to get into the double-digit TB range inexpensively. But, not everybody is going to do that. Most devices are going to have a relatively small (<500GB) storage footprint, ranging from phones and tablets (<=128GB) to laptops (<500GB). Newer laptops have extra space if you specifically add it but most people don’t. I have a 1TB secondary drive in mine and completely filled that up during this ripping project. So I started adding some 2TB USB drives. To get ones that look good next to the Shield, I’m somewhat limited as to the max space I can have there. Even when you look at enterprise decisions, small savings in space yield tremendous gains. Wasn’t it Dropbox that recently announced they’re re-encoding JPEGs now with their own internal proprietary compression to gain a 20% increase in space that resulted in PB of storage freed up. If I stuck to DVDs, I think I could maintain this. The growth rate of small USB drives and flash sticks is going to outpace the space I would need. But blu-ray discs are a different beast entirely. I’m working with 1080p only and h.265 Avatar was a 12GB, far larger with h.264. 10 epic BD movies will eat up a significant portion of a 1TB drive. I haven’t purchased one yet, but I’m itching to see what a 4K BD looks like. When presented with those file size options, I don’t know if drives in my form factor will scale and still be considered cheap.


Other Resources

    Phone

    (000) 000-0000 x12387

    Address

    1234 Somewhere Road #5432
    Nashville, TN 00000
    United States of America