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
💰 Please help cover server costs.
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.
What's AV1 compression like compared to x265?
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.
In my experience about ~8% better but 4x slower to transcode
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.
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.
Av1 would be great if everything supported playback, maybe soon. Tvs and chromecast with google tv 4k specifically. Somehow the 1080p one does
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.
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.
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.
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.
For a Jellyfin server however it's quite a boon.
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...
If your Jellyfin collection starts to grow big enough, and x264 transcoding on the fly is as easy as passing through the GPU these days...it's pretty much a no brainer. You have small files, and if someone still needs x264 (which would need to be specifically a Firefox streamer, as I believe Chrome supports it, and the Jellyfin apps also support it if your computer/phone does), the transcoding on the fly can be done using about 1-2% of the server CPU. I did something like 12 simultaneous different transcodes once, and my oldish i5 9500T held its ground perfectly, I think it reached about 35% CPU at the peak of it.
9500T has quicksync. That's why you're transcodes were only 1-2% on the cpu. You were doing transcoding on the built in gpu.
It is NOT trivial to do transcode without hardware decoding. How much utilization was on your 630 iGPU in that scenario?
Well it's a Jellyfin server. I bought a CPU that CAN transcode, for this specific purpose. Without hardware decoding, CPU usage scales quite quickly, but it could still hold 3-4 streams at 60fps I believe. At any rate, I bought this 2nd hand microPC with the specific purpose of being a Proxmox server with Jellyfin transcoding. And so, between having to consider further hard drive upgrades, or using the transcode function...I kinda choose the cheapest one since it's at hand.
Congrats? I'm running my Plex server on enterprise hardware. There's no onboard gpu for decoding because that's not the purpose of that hardware. I do have a graphics card in there to do transcodes, and intimately monitor that usage. My original statement still holds. "which could be a problem if you’re CPU limited or have no GPU for hardware transcoding."
Transcoding may not be that accessible/useful for some people. I'd rather waste some drive space than do transcodes for every user, but that's because I have 400TB(not a typo) of space but don't have enough space to put in any card that takes up more than 1pci slot. In my mind throwing another 20TB drive into my configuration is easier and cheaper than transcoding. In a couple of years we're going to be having this discussion for AV1 anyway.
Edit: Oh, and 3-4 streams at 60fps, isn't enough description... really doesn't cover the most taxing part of the transcode process, which is resolution. 3-4 1080p streams is much easier than even 1-2 4k streams. Considering that content is trending towards higher resolutions rather than higher framerates, I'm not sure what you're getting at. My T600 can do 3-4 4k streams before it starts running into problems. That should be something like 15-16 1080p streams. Considering my library, I'd still rather have the drives in a more accessible format that will direct play on more devices than transcode my 60-100mbps 4k videos. Keep the transcoding for those that really need it rather than making it the default answer.
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.
Yep, gpu de- and encoding is high-speed but often lower quality and with old codec versions. Common mistake to think that gpu = better.
In order to encode to a specific format without unintentionally losing quality, doesn't the initial file have to be a remux?
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.
You can downsample from BluRay, which would give you least loss.
But if you only have some good h264 version and want space savings, you can also reencode that, while probably loosing some small amount of quality, depending on your settings.
Indeed, but YMMV and to me quality is still good if source was not a remix but a top quality encoding
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
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.
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.
Word! My daily driver phone is old enough that I think it can only handle like, h236 or something at most.
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)
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/
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.
I've saved 4.02 TB of what was 28.12TB media collection.
How much kw and months did you use for that? 😮
I'm going to choose not to answer that for two reasons...
But yes I'm in a position where I was more willing to pay for the power than I was to buy additional storage space as I'm hitting the top of what I can do without significant expense.
solar panels and batteries are great.
Agree. That's why i want to place my mini-server on my dad's farm, he has solar on the roof.
I've always wanted to do that, but how do you handle seeding?
Just keep it seeding?
Of course if you want both, best space saving would be to use the same file.
I have multiple servers, so it doesnt really matter anyways, one machine downloads and seeds via its SSD and theother is just for storage on HDDs. Though i could setup tiered storage in this scenario to be able to seed more with same SSD strorage amount.
Ah, fair point. I don't use torrents, my media comes from usenet, so that doesn't need to factor into my thinking.
My (overly?) Complex setup does allow me to resort to torrents as a last resort, but that happens on another machine outside my home network and gets synchronised into my home via a one-way syncthing share, so even on the rare occasion I have to resort to torrents I can leave it on that server seeding for a few weeks or months.
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)