Hacker News Reader

Comment by NelsonMinar | Hacker News Reader

I've been using a lot of H.265 (aka x265/HEVC); some pirate scene TV and movie releases come out in it. It's fantastic. About 1/3-1/4 the size of H.264, which makes a huge difference both with download and with archiving. The downside is that there's not a lot of hardware support for encoding or decoding. Doing it on the CPU isn't bad but definitely not as energy efficient.

The problem with H.265 is the IP situation is a mess. AV1 looks to be better in every way. Looking forward to its adoption. So far the pirate scene doesn't seem to be using it at all.

View on HN

I think you're eating into quality loss if you're getting 33%-25% size, most every benchmark puts it at about 50%-60% size for equal quality to h264.

Pirating scene hasn't been using av1 at all because the bitstream hadn't been stabilized (an encode you made last month probably won't work on versions from this month) and, as a result of work still being done on the bitstream, no encoding hardware or software optimizations are available making it on the order of 3 magnitudes slower than existing options. Towards the start of 2019 you should start to see more hardware support pop up though.

> I think you're eating into quality loss if you're getting 33%-25% size, most every benchmark puts it at about 50%-60% size for equal quality to h264.

Do the benchmarks include animation? Perhaps flat surfaces like one sees in anime compress a lot better than average in x265?

Often, oddly enough. Anime groups in particular are obsessive about bitdepth, quality, and file size to the point it's not hard to find comparisons of lossless compression in newer codecs.

On the development and academic benchmarking side any comparison worth it's salt should have more than 5 different categories of video style. The paper linked in the article based their results on 20 different sequences, 3 or 4 of which looked to be animated.

One of the main reasons for the anime groups obsessing about the comparisons is that it's a lot easier to measure final quality on anime, with it's clearly-delineated artwork, instant transitions, and (comparatively) simple backgrounds.

I would also have guessed that many approaches for video/image compression like assuming lots of nice smooth gradients without hard edges, and so flat shaded but detailed drawn things might fare badly.

Hard edges are difficult for the DCT/DST used in most video codecs. A wavelet-based codec would most likely be better suited.

However, all modern codecs that I know of have directional intra prediction, which should be pretty effective in anime. Basically, what it does is that the decoder is able to follow lines with a variety of angles.

There are other things that help compression in anime: static frames, large flat areas, lack of film grain in computer drawn animation.

I would guess so, but looking at Nyaa atleast, there seem to be very little content encoded in HEVC compared to h264, which seems weird given how the 'anime scene' saw adoption of x264 10bit which is not even hardware accelerated.

With the supposed savings of HEVC versus h264, and the rather widespread HEVC hardware support in devices, I would have guessed that they would have embraced it at a larger scale by now.

Will be interesting to see what happens with AV1.

Does AV1 do subtitles? The reason most pirated videos use MKV instead of mp4 is because it does subtitles easily.

Subtitles have (almost) nothing to do with the video codec. AVI, MKV, MP4, etc. are container formats that are used to multiplex multiple streams of media (video, audio, subtitles) into a single stream/file. In contrast, AV1, x264, HEVC, etc. are video codecs stored inside a multiplex. Perhaps confusingly, he MPEG LA (which standardised x264 and HEVC) is also responsible for the MP4 container.

This is correct. The reason that the scene uses MKV is because it has better support for multiple audio, video, and subtitle streams and handles streaming as well as "streaming" from RAR compressed and split archive files.

> the MPEG LA (which standardised x264 and HEVC) is also responsible for the MP4 container.

The MPEG LA is just a licensing administrator formed by companies owning MPEG patents, they didn't standardize anything nor are they responsible for MP4 container.

The standards working group is MPEG, and according to Wikipedia the two are not affiliated ( https://en.wikipedia.org/wiki/MPEG_LA ).

You're absolutely right, sorry for getting this wrong. My mistake was to assume that the body that sells you the license is also responsible for the standardisation, but as you described, this is not true.

x264 is an AVC encoding software by VideoLAN.

Damn. How embarrassing! Two major factual mistakes in two sentences while nitpicking at someone else's mistakes on the internet. I of course meant to write h264 ;-)

AV1 is a video format, it has absolutely nothing to do with subtitles. AV1 videos are usually inside MKVs anyway.

AV1 is most expected to be used inside webm, though mkv can also package it.

webm is just a subset of MKV. They limited the codecs/options so that it would be easier have complete webm compatibility. (Whereas "full" MKV compatibility doesn't really make sense because it has ~infinite codecs you would need to support)

Furthermore webm/Matroska AV1 mapping isn't finalized, same situation with MP4.

Unless you encode the subtitles directly on the video stream, this is a container solution, the previous Google codecs (vp8/vp9) uses webm, which in turn is based upon mkv, so I would assume AV1 supports subtitles as easily if it uses webm as well.

Thanks for correcting me on quality. I'm getting confused because often the H.265 releases have low bitrate 2.0 audio compared to high quality 5.1 in the bigger file releases. They're optimizing for size, not fidelity. (I'm blessed with a tin ear and tin eye.)

So far the pirate scene doesn't seem to be using it at all.

Pirates, quite understandably, don't care about patents or IP. They can be a good indicator of whether there is any other reason to use AV1 over H.265.

AV1 is not simply ready. The specification is finished, but the encoder-decoder is not yet optimized. (It's considered experimental by ffmpeg for example. https://trac.ffmpeg.org/wiki/Encode/AV1 )

There's development happening here: https://aomedia.googlesource.com/aom/+log/refs/heads/master/...

> The specification is finished

Maybe not. There are still normative (i.e. changes affecting the spec) cases in the bug tracker:

https://bugs.chromium.org/p/aomedia/issues/list?q=label:Hotl...

In one of the tests rav1e encoded 1080p source at 0.013fps (i5-7600K @5GHz). That's half a year for a 2 hour movie.

Private torrent communities are already reluctant to use x265 which provides marginal gains compared to x264 at a great increase in encoding time.

A part of the process in pirate movie encoding (p2p, not really scene) is testing optimal encoder parameters (adaptive quantization strength, psychovisual rate-distortion, quantizer curve compression etc) on short clips meant to be representative of the whole movie (e.g. 60 frames every 4000 frames). If encoding a single test clip takes an hour as with x265 that sure puts a damper on things.

About the only place in movie torrent communities where x265 makes sense is 4K encodes as x265 can retain HDR metadata (h264 can too to an extent with the 2017 revision to T-REC H264 but it's hardly supported anywhere).

This may be different for pirate _streaming_ services.

> In one of the tests rav1e encoded 1080p source at 0.013fps (i5-7600K @5GHz). That's half a year for a 2 hour movie

This is easily explained by 1) no hardware acceleration, and 2) the reference implementation is currently intended for clarity and ease of changing, not efficiency or speed. After the bitstream solidifies, both problems will be solved.

> Private torrent communities are already reluctant to use x265 which provides marginal gains compared to x264 at a great increase in encoding time

Because there would be a clear quality loss. The websites they're ripping from (amazon, netflix, whatever) are using H.264, and to recode into H.265 would lose significant quality.

Netflix and Amazon also already encode in HEVC, they stream it to compatible players/hardware

>Because there would be a clear quality loss. The websites they're ripping from (amazon, netflix, whatever) are using H.264, and to recode into H.265 would lose significant quality.

This is wrong for two reasons: the source codec doesn't matter (it gets decoded to raw yuv420 first anyway), and netflix/amazon/UHD BluRays already use HEVC for 4K which I alluded to earlier.

The biggest downside is not energy efficiency IMO, it's speed. The speed difference between h.264 and h.265 encoding can be easily 10 fold. More-so on CPU reliant servers without GPUs. There is a big upfront sacrifice to get the small video size.

Even for decoding, you really need hardware acceleration. Trying to decode H.265 on one of these ARM based TV media players is an exercise in futility unless you have HW.

Pascal GPUs h265 encoding is 50% or higher than h264 encoding speeds. A single GTX 1080 can nvenc h265 8k@30 10bpp. A 150 dollar GPU will outperform a 3,000 dollar CPU only server in encoding (regardless if it's h264 or 265).

The REAL blockers are licensing and, more importantly, legacy consumer hardware. Whether you want to call the latter a speed or power problem isn't the real issue, it's that not all consumers have the dedicated hardware and the older CPU then has the speed and power problems.

With GPU encoding it's important to take into account that GPU encodes are usually delivering way lower quality levels per bit, especially if you're looking for fast speeds. The difference is dramatic if you compare a Twitch stream (for example) encoded with NVENC to one encoded with x264. Of course, hardware encoders let you achieve things that you simply can't do with CPU encoding, so sometimes that quality hit is irrelevant... but if you're talking about whether to use h265 instead of h264, it's possible the bitrate and quality improvements aren't that dramatic when you're using nvenc.

why do you specifically mention GTX 1080? There is zero difference between 1050ti and 1070 when it comes to encoding, does 1080 change anything?

Anecdotal evidence, and possibly an FFmpeg/Nvenc bug

I've found that I'm not able to encode video above the size of the VRAM on the GTX 1050 in my home server. It seems to spew out errors, despite the GPU's memory usage being roughly 60MB from ffmpeg

My GTX 1080 meanwhile seems to happily churn through anything and everything thrown at it

NVENC quality is crap.

https://youtu.be/jludqTnPpnU?t=366

>There is a big upfront sacrifice to get the small video size.

Still, the benefit to the millions of people who might download and watch a video surely outweighs the cost of the one individual computer that spent 10x the amount of CPU cycles encoding it.

Piracy "scenes" have an eternal pissing contest about being the "first" to release something. Bragging rights seem to trump quality, unfortunately

The biggest downside is that your phone / tablet / etc can hardware decode h.264, and has to run h.265 or av1 decoding in software. As a result, your battery life gets killed when watching h.265 / av1.

This is indeed a downside right now, but won't be once hardware support is in.

That's expected on new devices at some point next year.

Where are you finding HEVC encoded pirate content?

I railed against "scene" groups for many years over the quality (or lack thereof) in releases they put out. To the point I simply started buying the media I wanted, ripping it myself and then converting it to HEVC

Doing as close to a 1:1 DVD rip as I can, I've shrunk things like Seinfeld from 152GB of MPEG-2 video to just 31GB in HEVC, and it still looks absolutely fantastic

HD video fares even better. The X-Files on Blu Ray is roughly 1.7 terabytes. HEVC encoded brings it down to 240GB or so

Quick look at http://m.thepiratebay.org/search/x265/0/0/0 returns a huge number of results.

PSA Rips is a good place to look if you're curious about how H.265 is used in practice. (Note the 10 bit video.) Their stuff tends to be tagged "hevc-psa". Here's an article they wrote about encoding quality: https://psarips.com/why-psas-releases-are-sometimes-late/

That sounds like they're re-encoding releases by other groups? If so I wouldn't trust anything they say about quality.

I don't think so; their releases seem mostly to be WEB-DL from the original source streams. They seem pretty sophisticated about it, I don't think they're doing something stupid like trying to turn an 8 bit source into a 10 bit rip.

The linked post can't be referring to web-dl as that wouldn't involve them doing any encoding, just removal of DRM.

Edit: as I suspected, they are reencoding from other groups. At least they make it clear I suppose:

"Preacher.S03E04.The.Tombs.1080p.WEBRip.6CH.x265.HEVC-PSA 447mb.

Source: Preacher.S03E04.The.Tombs.1080p.AMZN.WEBRip.DDP5.1.x264-NTG | 2.38 GB"

No way that could look as good as the x264 and the video has been encoded three times, amazon->NTG->PSA.

Hardware support for decoding should be pretty good these days. Any TV or streaming box that supports 4k streaming should support HEVC, since AFAIK all the streaming sources use it (except for YouTube, last I checked). I suppose if you’re streaming on a laptop you might be stuck with software decoding.

I’m also very impressed with HEVC, but mostly from the angle of UHD Blu-rays. The quality is remarkable. For the same size or slightly larger than 1080p Blu-rays (around 50GB, sometimes up to 70), you get 4k resolution (4 times the pixels as 1080p) and HDR.

>The problem with H.265 is the IP situation is a mess.

I really wish the next gen codec, H.266 VVC could sort this royalty mess out before hand.

Why cant we keep things simple. USD $1 Per devices Royalty on Hardware encode and decode, that is roughly $3B + Royalty every year for the next 20 years.

Software Implementation should be free. So an H.266, VVC based image and video decoder could be immediately rolled out to all PC, and browser vendor could support it.

One of the problem with current MPEG codec is that they are too worry about free software implementation take over their royalty. Well we don't have huge increase in IPC anymore. We have a roadmap from TSMC that shows us the next 10 years of leading edge transistor is going to be more expensive then ever. We don't have any breakthrough / theory on hand they we could make those a lot cheaper. The days of Moore's Law are long gone.

This allow hardware maker to sell "faster" video and picture decoding. Consumers are a lot easier to spend money on physical object, then paying $x for faster software. Once they felt how slow their images and video were, it give them an incentive to upgrade, PC, Tablet, Phone etc.

Reply on news.ycombinator.com