I'm sad they skipped out on a 4k resolution test. I'd really like to see how they compare at those resolutions or higher, since really x265 isn't really going to be ubiquitous in hardware for another couple years. At that time 4k should (hopefully) be the standard, or at the very least will be a common use case.
Ah excellent. Saw the presentation info stuff and stopped reading. Glad to see it - plenty of debates among friends about the actual performance of h265 at 4k, so I'm excited that they're doing it.
It's much simpler and easier to use formats which are licensed under royalty-free terms, which is what VP9 offers now and what AV1 will also offer in future:
To me the important result from Netflix's test is that VP9 is better than H.264, almost as good as H.265, and absent the patent licensing problems. I think the simpler licensing makes VP9 the better choice today and AV1 the best choice in the future.
Realistically it will probably come down to what's implemented in hardware. Youtube's 4k video in chrome is really a terrible experience when you don't have hardware acceleration for vp8. It pegs your CPU at nearly 100% and god help you if you're viewing a 4k 60fps video.
Browser support is the most important factor for web video. H.265 currently has no browser support but VP9 is supported by Firefox, Chrome, Microsoft Edge, Opera, Vivaldi, etc.
I'd say there's a reasonable chance, and if not VP9 then definitely AV1. The next version of macOS and iOS supports WebP (a still image format based on VP8) so the VP8/VP9/AV1 family has a foot in the door:
What makes you think that 4k 60fps is even possible without hardware acceleration? That's 12.7 Gbps output bandwidth (assuming true color), barely possible even using just memcpy, let alone decoding.
Interesting point. However, just to be pedantic, if memory bandwidth were the only bottleneck, you'd expect video decoding to generate output faster than memcpy, since it wouldn't have to read as much :-)
My Intel NUC cost me £300 in January and is therefore a fairly low-end machine. It has 307 Gbps of memory bandwidth (2 slots of DDR4-2400). It's surprising how big that number is on a cheap machine today.
I'd love to see a profile of where the CPU time goes in a modern CPU-only video decoder. I guess I could get off my arse and do the profiling myself instead of posting this. Anyway, my guess is that the processor speed is the bottleneck, not the memory bandwidth.
That's mostly partial acceleration. Chips now support a lot of codecs. And aside H264/AVC chips makers cannot afford to use so much hardware surface for codecs that are not so popular.
You must be talking about either a wimpy laptop CPU, a cellphone or a tablet.
Old desktop Sandy Bridge does 4k 60 FPS decoding with no problems, as long as output can sustain it. And integrated GPU does not. You need quite a lot of bandwidth to sustain that much image data.
It's always weird to read codec commentary from broadcast people; their world and concerns are just so alien to me. I also rather wonder what he considers a raw bytestream that HEVC has and VP9 doesn't...
Anyway, I guess the only major concern from him is the DCT overflow? I mean, for the extra precision, even HEVC has increased from 16-bit intermediates in the newer profiles. I think Daala's transforms would solve his issues with VP9's, I'd imagine they're being considered.
It depends... the better the input and larger the resolution, the better x265 works for a given display. On the other side, I recently started re-ripping my DVDs of Babylon 5 for seasons 4-5 (had already watched seasons 1-3 on dvd) via Handbrake. I had to play a lot with the settings, and found that for DVD, a constant quality level 18 at medium seemed to work about best without losing too much quality. This resulted in a file size anywhere from around 290mb to 390mb, so some variance in size, for local data store this works fine, for online streams this wouldn't work as well, and would probably want a 2-pass for a consistent bitrate. This is compared to an average 850mb or so file size for the prior rip to x264. The time to encode (i7 4770k) seems to be about 13-16 minutes per episode. Again, this is at DVD source/output quality.
At 1080p, you can lower the quality to around 22-24, and get near blue-ray output... the flatter the input (animation is a great example) the bigger the difference. I'm seeing encodes at 40-60% of comparable blue-ray.
The down side, is it is significantly slower, and the quality of the x265 version of the codec is much better than say the nvidia x265 encoder, which is a shame as it's much slower too, so it becomes kind of a non-option for archives imho.
If you are encoding new media for your library, definitely go x265, it's worth the file size saving (so long as your playback devices support it well enough), but I wouldn't go back and re-encode it all, it's just too slow for now... maybe if x264 gets some CUDA support, that would be really nice (recently upgraded to a 1080 GTX).
The sizes you quote for B5; are those per episode or per disc?
Also, using a 3d denoiser on B5 will drop the bitrate a huge amount without trading off much quality. There is significant grain in those (though seasons 1-2 were worse than 3-5 IIRC).
Per episode... I used the 3d denoiser at low setting, which helped a lot. I know Seasons 1-2 are really bad in terms of quality, which is why I mentioned it.. suspecting that s1-2 will be closer to the larger sizes because of it.
The filter hqdn3d is what you want. Note that the defaults are for noisy video, so unless you have a really noisy source you'll want to use lower settings. I've seen hqdn3d=4:4:3:3 as a good place to start, and you can tune the numbers (lower is more noise, less blur, higher is less noise, more blur). In addition, the default values for each parameter is scaled based upon the previous value(s), so you can be lazy and just pass one or two values to get a coarse idea of the strength you want.
If the videos are to be played back on a player that supports video filters, you can add some noise back in on decode, which is particularly useful for non-HD sources as your eyes will often interpret noise as detail. Back in the h.263 days I used to do this as 1) h.263 was much worse than 264 or 265 and handling noise and 2) disk space was more expensive, so I couldn't just up the bitrate. I still have some vlc settings that can do that for playing old DVD rips. Today, unless you plan on streaming the video, I would recommend just upping the bitrate and using conservative enough denoise settings to not need it.
x265 is actually worse than x264 on high bitrate content, which is why its use is banned on private trackers where picture quality is totally paramount.
x265 tends to smooth out film grain that x264 preserves at high bitrates. That being said - Netflix has never offered x264 content at sufficiently high bitrates (visually indistinguishable to Blu-ray quality) anyway, so it's a moot point.
It doesn't need beefier hardware its just not implemented in most SOCs or GPUs so it uses software decoding.
X264 was also a hog when it didn't had dedicated hardware decoders now everything even your microwave can probably decode it in hardware.
> x265 outperforms libvpx for almost all resolutions and quality metrics, but the performance gap narrows (or even reverses) at 1080p.
It's not clear if this means libvpx is sometimes better than x265 at resolutions > 1080p or <= 1080p. I think the author intended "occasionally better when <= 1080p"
I've been playing around with reencoding all my media to H.265/HEVC at home. The space savings over the older H.264 are around 50% (or better!) depending on what I encode
I have a lot of digitized box sets of TV shows, things like The Simpsons or King of the Hill. Most bit torrent copies of these shows weigh in at about 180MB/episode (for a 480P video)
Encoding them through H.265 using NVIDIA's "Nvenc" encoder (CPU encoding is paaaainfully slow) I can get them down to a mere 60MB on average, with no discernible quality difference
Moving up to 1080P files, I encoded some Star Trek: The Next Generation digital remasters, they shrunk from 600MB to about 350-400MB. Not quite as impressive, though I had to scale up the quality as HEVC was wrecking havoc on some of the low contrast areas (like character uniforms turning into one flat smeared looking color)
I imagine the biggest difficulty is the licensing for x265. It may have changed now but from last I knew they wanted a royalty from streaming services monetizing the use of x265.
It looks like there have been a few dead ends -- clever ideas that for one reason or another didn't pan out -- but overall, it's making solid progress. It remains, however, very experimental and is far from complete.
One area in which Daala works very well right now is in compression of still images. There's a demo at the bottom of the page which shows it as much better than HEVC for that purpose, and you can also see how the codec has improved over time. Of course, the relative goodness of codecs isn't necessarily consistent over widely varying bitrates.
In some of the earlier posts the Daala researchers expressed the belief that the quantitative metrics often don't accurately correspond to subjective perception of quality. Netflix seems to be putting a lot of work into developing better metrics [1], but the Daala researchers seem to rely on subjective A-B tests as the 'gold standard'.
I think they're treating Daala as a research platform these days. AV1 is the future for video on the web and code from Daala has been contributed to it. AV1 is based on ideas from VP10 and Daala:
From what I understood, Daala was never meant to be a competitor to x265, but a research project that could create a competitor for the next generation, while using no techniques that could questionably come under current patents.
I find it odd that Netflix is using Youtube and Periscope to do their broadcast. I get that that is where the audience is - but I'm surprised they aren't also broadcasting it using their own tech.
On the contrary, I always find it refreshing to see companies use each others existing tech - particularly, when they don't have anything new/worthwhile to offer end-users (in this case, a dev audience) other than introducing an unnecessary inconvenience or dependency.
Frequently the conference organizers will be handling the AV setup for an event. Its likely much easier and common to get this content onto Periscope, and YouTube for those folks then some custom Netflix deal.
1) Forbid active web content unless it comes from a secure (HTTPS) connection would, I assume, block the active elements, not redirect the entire page to HTTPS.
2) I had it set as:
Forbid active web content unless it comes from a secure (HTTPS) connection
= Never
You'd think that would disable it, but according the question just above the one you linked, Never apparently means Always unless the site is whitelisted:
----
Open NoScript Options|Advanced|HTTPS|Behavior, click under Forbid active web content unless it comes from a secure (HTTPS) connection and choose one among:
1. Never - every site matching your whitelist gets allowed to run active content.
2. When using a proxy (recommended with Tor) - only whitelisted sites which are being served through HTTPS are allowed when coming through a proxy. This way, even if an evil node in your proxy chain manages to spoof a site in your whitelist, it won't be allowed to run active content anyway.
3. Always - no page loaded by a plain HTTP or FTP connection is allowed.
