this post was submitted on 24 Feb 2024
217 points (95.8% liked)

Piracy: ꜱᴀɪʟ ᴛʜᴇ ʜɪɢʜ ꜱᴇᴀꜱ

54476 readers
718 users here now

⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.

Rules • Full Version

1. Posts must be related to the discussion of digital piracy

2. Don't request invites, trade, sell, or self-promote

3. Don't request or link to specific pirated titles, including DMs

4. Don't submit low-quality posts, be entitled, or harass others



Loot, Pillage, & Plunder

📜 c/Piracy Wiki (Community Edition):


💰 Please help cover server costs.

Ko-Fi Liberapay
Ko-fi Liberapay

founded 1 year ago
MODERATORS
 

Nearing the filling of my 14.5TB hard drive and wanting to wait a bit longer before shelling out for a 60TB raid array, I've been trying to replace as many x264 releases in my collection with x265 releases of equivalent quality. While popular movies are usually available in x265, less popular ones and TV shows usually have fewer x265 options available, with low quality MeGusta encodes often being the only x265 option.

While x265 playback is more demanding than x264 playback, its compatibility is much closer to x264 than the new x266 codec. Is there a reason many release groups still opt for x264 over x265?

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 127 points 8 months ago* (last edited 8 months ago) (1 children)

A lot of TV shows are direct rips from streaming services and they don't use H.265 because of the ridiculous licensing it comes with.

I suspect AV1 will become much more popular for streaming in a few years when the hardware support becomes more common. It's an open source codec, so licensing shouldn't be an issue. Then we will see a lot more AV1 releases.

[–] [email protected] 25 points 8 months ago (4 children)

What's AV1 compression like compared to x265?

[–] [email protected] 34 points 8 months ago

It's comparable, sometimes better

[–] [email protected] 12 points 8 months ago

In my experience, you always gain space savings going av1 from 264 and 265 as well. For me its always been significant savings at the same quality level.

Ofc YMMV and use a very recent ffmpeg with the best av1 libraries.

[–] [email protected] 10 points 8 months ago

In my experience about ~8% better but 4x slower to transcode

[–] [email protected] 4 points 8 months ago

Pretty big in my experience

[–] [email protected] 63 points 8 months ago (1 children)

x265 playback is more demanding than x264 playback

By a factor of 2 with the same bitrate. But you only need half the bitrate for the same quality (SNR) so it really isn't.

However, encoding is about 10x more demanding in terms of bitrate, or 5x for the same quality. This may be worth it for long-term storage or wide distribution over limited bandwidth (torrenting), but not for one-time personal use.

[–] [email protected] 18 points 8 months ago (2 children)

For a Jellyfin server however it's quite a boon.

[–] [email protected] 10 points 8 months ago (2 children)

Did you do something specific to play x265 on JellyFin? Last time I tried, the video kept crashing every 5-8minutes, even with a low bitrate threshold.

[–] [email protected] 8 points 8 months ago (3 children)

Which client? Works fine here

load more comments (3 replies)
load more comments (1 replies)
[–] [email protected] 10 points 8 months ago (4 children)

Only if you're disk limited or bandwidth limited. And in many cases will lead to transcoding the content, which could be a problem if you're CPU limited or have no GPU for hardware transcoding.

Everything (not literally... but figuratively) can do x264. Not everything can do x265...

load more comments (4 replies)
[–] [email protected] 62 points 8 months ago (3 children)

Go AV1... In my direct experience the space saving is simply amazing at the same quality.

265 doesn't seems to be the future since all Android are going to support AV1 by mandatory from A14.

[–] [email protected] 34 points 8 months ago

I recently started transcoding my media to save some space, and I went with h265 instead. AV1 will be great in a few years, but the hardware support is just not there yet.

[–] [email protected] 19 points 8 months ago* (last edited 8 months ago) (2 children)

Av1 would be great if everything supported playback, maybe soon. Tvs and chromecast with google tv 4k specifically. Somehow the 1080p one does

[–] [email protected] 13 points 8 months ago* (last edited 8 months ago)

Will still be at least 10 years away sadly for it to be truly ubiquitous... Remember I couldn't play x265 properly for quite a while.

[–] [email protected] 6 points 8 months ago

I got an amazon fire stick, all the new ones support av1 and all android devices from A14 must support av1 too.

On PC vlc plays it just fine too.

[–] [email protected] 8 points 8 months ago

It doesn't play well on older kit though. Even the Nvidia Shield Pro won't play them unless they're really low resolution.

265 is ideal for me, even if it's hamstrung on open source browsers.

[–] [email protected] 31 points 8 months ago (3 children)

Some notes: Don't use GPU to reencode you will lose quality.

Don't worry for long encoding times, specially if the objective is long term storage.

Power consumption might be significant. I run mine what the sun shine and my photovoltaic picks up the tab.

And go AV1, open source and seems pretty committed to by the big players. Much more than h265.

[–] [email protected] 14 points 8 months ago (5 children)

Why is the GPU reencoding bad for the quality? Any source for this?

[–] [email protected] 8 points 8 months ago* (last edited 8 months ago)

I have some comments based on personal experiences with GPU av1 encoding: you will always end up with either larger or worse output with GPU encoding because currently all the encoders have a frame deadline. It will only try for so long to build frame data. This is excellent when you are transcoding live. You can ensure that you hit generation framerate goals that way. If you disable the frame deadline, it's much much slower.

Meanwhile CPU encoders don't have this because CPU is almost never directly used in transcoding. And even with a frame deadline the output would still not be at the same speed as the GPU. However the CPU encoders will get frames as small as you ask for.

So if you need a fast transcode of anything, GPU is your friend. If you're looking for the smallest highest quality for archival, CPU reference encoders are what's needed.

[–] [email protected] 6 points 8 months ago (2 children)

Yeah that caught my eye too, seems odd. Most compression/encoding schemes benefit from a large dictionary but I don't think it would be constrained by the sometimes lesser total RAM on a GPU than the main system - in most cases that would make the dictionary larger than the video file. I'm curious.

[–] [email protected] 21 points 8 months ago (9 children)

It's not odd at all. It's well known this is actually the truth. Ask any video editor in the professional field. You can search the Internet yourself. Better yet, do a test run with ffmpeg, the software that does encoding and decoding. It's available to download by anyone as it's open source.

Hardware accelerated processing is faster because it takes shortcuts. It's handled by the dedicated hardware found in GPUs. By default, there are parameters out of your control that you cannot change allowing hardware accelerated video to be faster. These are defined at the firmware level of the GPU. This comes at the cost of quality and file size (larger) for faster processing and less power consumption. If quality is your concern, you never use a GPU. No matter which one you use (AMD AMF, Intel QSV or Nvidia NVENC/DEC/CUDA), you're going to end up with a video that appears more blocky or grainy at the same bitrate. These are called "artifacts" and make videos look bad.

Software processing uses the CPU entirely. You have granular control over the entire process. There are preset parameters programmed if you don't define them, but every single one of them can be overridden. Because it's inherently limited by the power of your CPU, it's slower and consumes more power.

I can go a lot more in depth but I'm choosing to stop here because this can comment can get absurdly long.

load more comments (9 replies)
[–] [email protected] 7 points 8 months ago

The way it was explained to me once is that the asic in the gpu makes assumptions that are baked in to the chip. It made sense because they can't reasonably "hardcode" for every possible variation of input the chip will get.

The great thing though is if you're transcoding you can use the gpu to do the decoding part which will work fine and free up more cpu for the encoding half.

[–] [email protected] 4 points 8 months ago* (last edited 8 months ago)

Already been explained a few times, but GPU encoders are hardware with fixed options, with some leeway in presets and such. They are specialized to handle a set of profiles.

They use methods which work well in the specialized hardware. They do not have the memory that a software encoder can use for example to comb through a large amount of frames, but they can specialize the encoding flow and hardware to the calculations. Hardware encoded can not do everything software encoders do, nor can they be as thorough because of constraints.

Even the decoders are like that, for example my player will crash trying to hardware decode AV1 encoded with super resolution frames, frames that have a lower resolution that are supposed to be upscale by the decoder. (a feature in AV1, that hardware decoder profiles do not support, afaik.)

load more comments (2 replies)
[–] [email protected] 11 points 8 months ago* (last edited 8 months ago)

Yep, gpu de- and encoding is high-speed but often lower quality and with old codec versions. Common mistake to think that gpu = better.

[–] [email protected] 4 points 8 months ago (3 children)

In order to encode to a specific format without unintentionally losing quality, doesn't the initial file have to be a remux?

[–] [email protected] 7 points 8 months ago

Yes, that's right. But the point stands, you indeed shouldn't do such encoding on the GPU, it's a tradeoff of (fast) speed vs (poor) quality and (big) size. Good for when you need realtime encoding.

load more comments (2 replies)
[–] [email protected] 30 points 8 months ago (5 children)

RARBG was so good for this, their releases were of such good consistent quality

If you search for ORARBG on therarbg site you can still find some OG releases and not random YIFY crap

load more comments (5 replies)
[–] [email protected] 28 points 8 months ago (1 children)

MeGusta and Im pretty sure all other x265 groups aren't really considered official scene releases and usually the sources are the larger x264 scene releases. I've found that you can get the same if not better results as MeGusta encoding with a simple -cq 27 with the nvenc_h265 encoder which is reasonably fast.

A good portion of the world thats pirating media is playing it cheap junk with 10+ year old CPUs that can't handle x265, most do not have terabytes of media they just watch and delete so overall size isnt a huge issue, most likely when a new codec does become more mainstream, it won't actually mean smaller releases anyway, it will just mean better quality ones.

In the 00's the standard everyone used was 800mb DivX because thats the size CD-Rs came in, over time, going into the 2010s we got x264 releases but the targets were around 4-8gb usually and by that point the size of optical media didn't really matter since flash drives are cheap and reusable and overall internet speeds for people continues to increase as well so its more likely that when the day comes, the scene will probably coalesce around something like 8-16gb per release.

[–] [email protected] 6 points 8 months ago

That's why I grab the Chinese versions of stuff in the original language, they seem to not care about license and encode in h265 in the app

[–] [email protected] 18 points 8 months ago (3 children)

I’d be interested to know how many of the streaming services natively offer x265. If it’s not many, then I could understand why release groups wouldn’t wanna re encode (e.g. it wouldn’t be a true WEB-DL anymore)

[–] [email protected] 5 points 8 months ago (1 children)

Prob 0 % as h265 is like HDMI and needs to be licensed to be used. Sadly this has set up 265 to be a failure outside of piracy

[–] [email protected] 12 points 8 months ago* (last edited 8 months ago)

It's used for the majority of HDR streams and all Dolby Vision streams. h265 is the only codec that supports DV

load more comments (2 replies)
[–] [email protected] 15 points 8 months ago (1 children)

There's always the chance that compatibility / breadth can be a factor. I don't know how much more demanding 265 is than 264 but if it is "noticeable" / "enough", if it means someone can't play the content in their (smart) TV set or on their phone, it makes sense then to release for the more compatible option / avoid a dual release.

[–] [email protected] 4 points 8 months ago* (last edited 8 months ago) (1 children)

My old laptop can't handle h265. I don't think my old SmartTV can, either. We need h264 for those devices since they both have dedicated h264 decoding hardware.

load more comments (1 replies)
[–] [email protected] 13 points 8 months ago

I had no idea about the differences with h264 / 265.

Interesting article to skim here for the uninitiated https://www.techspot.com/article/1131-hevc-h256-enconding-playback/

[–] [email protected] 10 points 8 months ago

I only download h265 because my drive is filling up as well. I can usually play it back easily in software, except for film grain that wrecks the performance

[–] [email protected] 6 points 8 months ago (6 children)

I've just recently started using tdarr to convert all of my media to x265on 14/02 and so far I've saved 4.02 TB of what was 28.12TB media collection. (The number isn't a true reflection though because new episodes and shows have been added to that library since I started)

I'm letting tdarr manage the conversion process and once up and running meant that my NAS, desktop, my NUC and a mini pc are all plodding through and converting when I'm not using them for other things.

If you are worried about the disk space being taken and have some CPU time you can devote to the conversion process then I'd suggest it's worth looking into tdarr.

load more comments (6 replies)
[–] [email protected] 5 points 8 months ago

I've done a bunch of transcoding of things to x265 in the past (as I'm sure everyone is aware transcoding isn't GREAT but cuts down on storage costs). With that said I've now moved to AV1. I don't use GPU encoders at all as I found the quality to be pretty terrible. I just use a custom written ZSH script to go through and check the current format (it also converts audio to OPUS too)

load more comments
view more: next ›