|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|
|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|
|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|
|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|
|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|
|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|
|So, things can only get better! I’ll keep you posted.|
|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.|
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.
@joegood I was talking about hi10p (x264 10bit). HEVC is x265 10bit and it's actually being supported by a lot of manufacturers. It's relatively easy to find a box that's able to reproduce HEVC these days and the nvidia shield should reproduce them without any issue whatsoever. Some groups are releasing anime using HEVC but too few to matter. I think most are actually going to stick with hi10p if you can believe it. So for the foreseeable future we're still gonna be able to reproduce a 1080p 15gb rip of an Avengers movie in our phones flawlessly (shit movies but I'm making a point here) but not a 22 minute, 300mb episode of an animated series. Which makes a lot of fu****ng sense.
I'm tired of all the misconceptions so let me explain this as simply as possbile:
So congratulations, you all drank the kool-aid.
TL;DR IF THE SOURCE IS 8-BIT, CONVERTING IT TO 10-BIT WON'T MAKE THE OUTPUT SMALLER OR BETTER. The gains in filesize and image quality are all due to the fact that the comparison is between a modern codec and a very old codec. DO NOT DITHER YOUR ENCODES as you are simply adding noise. If the source has banding, get a better source, or check if perhaps your display is uncalibrated and the actual cause of the banding.
Actually I am now trying to edit videos on my iPad for the first time and do some color corrections - Prores is basically out of the question, so I guess this 10-bit h264 is pretty neat. Those colors definitely wont be useless, in fact, 10-bit h264 is quite a good compromise between highend and lowend when it comes to the video codecs.
Good lord am I one confused idiot/noob lol.
The only one not being rational here is the one person not putting forward an actual argument (you), deciding to launch personal attacks instead. Next time try to keep it "rational" and post something of substance.
Okay I stumbled upon this thread while looking for a decent way to re-encode 10-bits h264 to 8-bits h264. Hi10 has basically been around for almost a decade now (you can find some XBMC thread from 2011 talking about hi10 support) and some groups still insist on it being great for whatever reason. I kinda gave up trying to reason them, and hardware support is still non-existent (and probably won't be, ever).
This will be pretty slow, you could potentially speed it up by lowering --crf (and therefor increasing bitrate), --crf 0 is effectively a lossless file (from a lossy source if you're transcoding Hi10p releases). You could also consider using nvenc if you have a nvidia GPU, it's extremely fast compared to cpu-based encoding (over 20x faster on my machine) however the end result won't be as good as x264 at the same bitrate (I'm unsure of AMD has an equivalent).
@HyerrDoktyer I totally agree with you on the 8 bit releases... when they are available. I've recently tried to catch up on some 'older' shows (> 3 years old) and some of them (rare but not 0) only have 10 bit releases now. It's only for those that I'll bother doing that.
I don't think it will worth it if you convert 8-bit video to 10-bit video before encoding. It doesn't reduce file size as is shown in my experiment:
It seems that converting to 10-bit will consume larger disk space in order to get the same quality. So using 8-bit encoding directly may be better.
I did another experiment, which indicates the same:
The command I use to generate the test files:
+1 for the introduction, it gave me a solid laugh, couldn't agree more.
Some people here should not make fools of themselves in bold capslock. I am not knowledgeable enough to verify if the article is right or not, but I know for sure that comparing lossy audio with video is like comparing Norwegian poetry with reflecting tape for traffic cones.