Jellyfin/Emby best Handbrake encoding strategy

[SpeedBird999]

Hi everybody

I'll explain my problem briefly: due to surging power bills here in Europe and the fact my current one is broken I wanna switch my Jellyfin/Emby media server to a Raspberry Pi. Unfortunately, new RBPis are sold out everywhere and so I'm stuck with an old one I have laying around (a B+ from 2014/2015). It's nice from a reduce/reuse prospective, but that board's SOC is of course old and slow, and won't support any kind of live trans-coding of video content. So i set myself up to convert my entire video library to formats which wouldn't need to be trans-coded by the server but could be played directly by the clients. The clients in question are a WebOS 5 TV (which thanks to LG's amazing OS fragmentation, will probably never get the Jellyfin app and that's why i'm also running Emby), various iOS and Android devices and several PCs (using the apps, I'm not interested in browser streaming).

And here are my doubts (I'm kind of new to this all video trans-coding world). I would answer them by live testing the whole thing, but unfortunately my current media server is down for other issues and i would like to be certain of this strategy actually working before ripping out the Raspberry from its current use and setting up this new media server on it.

MP4 H264 AAC 8bit seems like the safest bet, every sort of device seems to support it, but it's not as disk-space and bandwidth efficient as H265 and furthermore the latest version of Handbrake doesn't allow to take advantage of Nvidia's GPU NVENC encoder for it (i don't know why, after googling it out it seems that it used to be supported but that's no longer the case) meaning much longer trans-coding times (4 or 5 times as much, with my machine R5 3600 Quadro P4000). These factors are tempting me to go for H265, but while Jellyfin's forum has a table that would suggest that every device I use is compatible with H265, such information is nowhere to be found on Emby's blog/forum; my TV supports H265/HEVC but I came to understand (again not sure if true) that the app itself needs to be compatible with the format, it's not a given of the TV's hardware.

Also, I've ended up in a Google rabbit hole of people saying that NVENC is garbage, that it destroys video quality and that shouldn't be used to re-encode stuff, others saying it's the greatest thing since sliced bread...I'm kind of confused honestly.

The main question then is: can i get away with H265 given the compatibility doubts, and should NVENC be seriously considered (both for H264 and H265)?

If you could help me, that would be much appreciated. Thanks everybody.

[jaslion]

So basically its a nas?

 

Id just acess the folder structure via a filevrowser and play the files or well just leave it in whatever form its originally and ad long as the network can handle it (and device) thry'll encode it fine.

 

As for disk space efficiency unless you have a decently old device use hd265. If its the lg tv being an ass (as it already is with emby only) just get a 30$ roku still and unschakle yourself from built in tv oses

[Takumidesh]

10 minutes ago, SpeedBird999 said:

NVENC is garbage, that it destroys video quality and that shouldn't be used to re-encode stuff

why do you need to re-encode or transcode stuff? the only reason I can see to switching to h.265 is for space. but it didn't seem like that was an issue in your case?

 

if you just pick a safe container and a/v codec like like mp4, h.264, ac3. You should be good on 99.9% of clients, and the rpi won't need to do any transcoding.

 

[SpeedBird999]

1 minute ago, jaslion said:

So basically its a nas?

 

Id just acess the folder structure via a filevrowser and play the files or well just leave it in whatever form its originally and ad long as the network can handle it (and device) thry'll encode it fine.

 

As for disk space efficiency unless you have a decently old device use hd265. If its the lg tv being an ass (as it already is with emby only) just get a 30$ roku still and unschakle yourself from built in tv oses

I was thinking of installing a desktop style distro on the Raspberry and running Jellyfin/Emby on it, so it wouldn't really be a NAS. Furthermore, the media server has to work for other people too and they're not exactly tech savy.

I had already thought about an HDMI dongle, but aside from having to deal with one more remote and to free an HDMI on the TV, the Roku aren't sold here and getting Jellyfin working on a FireTV stick seems kind of tricky from what I've read.

[SpeedBird999]

1 minute ago, Takumidesh said:

why do you need to re-encode or transcode stuff? the only reason I can see to switching to h.265 is for space. but it didn't seem like that was an issue in your case?

 

if you just pick a safe container and a/v codec like like mp4, h.264, ac3. You should be good on 99.9% of clients, and the rpi won't need to do any transcoding.

 

Currently my library is all over the place. I've got multiple formats, lots of uncompressed stuff...i though if I'm re-encoding the whole library might as well do it right and while I'm at it why not optimize space too and also the time spent doing the re-encoding (that's why I'm considering H265 and NVENC respectively).

[Takumidesh]

3 minutes ago, SpeedBird999 said:

Currently my library is all over the place. I've got multiple formats, lots of uncompressed stuff...i though if I'm re-encoding the whole library might as well do it right and while I'm at it why not optimize space too and also the time spent doing the re-encoding (that's why I'm considering H265 and NVENC respectively).

why not re rip everything from scratch then? re-encoding always results in worse quality.

 

converting from lossy A to lossy B is very time consuming, energy hungry, and will always result in worse than just encode from the rip.

 

if you do end up ripping the movies again, or re encode the raws then, based on the fact that you have a lot of various clients, I would go with h.264, again, I don't really see any point in h.265 unless you are really tight on space, but hard drives are cheap.

 

For context, i actually did all this, so this is based in my experience. I re-encoded all my h.264 movies (around 800) into h.265, not from scratch, but from the h.264 encode.

 

it took like 2.5 months of non stop work, ryzen 9 5900x and an i7-8700k, nearly 24/7. the result was, about 1/3 space saved. and a general overall reduction in quality.

[SpeedBird999]

1 minute ago, Takumidesh said:

why not re rip everything from scratch then? re-encoding always results in worse quality.

 

converting from lossy A to lossy B is very time consuming, energy hungry, and will always result in worse than just encode from the rip.

 

if you do end up ripping the movies again, or re encode the raws then, based on the fact that you have a lot of various clients, I would go with h.264, again, I don't really see any point unless you are really tight on space, but hard drives are cheap.

Absolutely, re-encoding from a compressed thing to another one leads to losses, no question about it.

But honestly re-ripping everything would be much much much more time consuming...Handbrake can be set up and left to run on its own, while swapping DVDs and Bluerays in and out and then encoding them requires a lot of personal time in front of the machine

On the space front, I'm not necessarily constrained but i mean if i can get away with it, I'd go H265. It's more future-proof, more efficient and leaves me with more free disk space which would be a nice bonus.

[Takumidesh]

1 minute ago, SpeedBird999 said:

It's more future-proof

what does this mean exactly?

 

as it stands, h.265 has less support, and new codecs (av1) are already being released that can perform better than h.265

 

I would argue that an h.264 encode is more future proof as it doesn't require as much dedicated hardware and can easily be decoded by most CPUs with pretty minimal effort.

 

4 minutes ago, SpeedBird999 said:

leaves me with more free disk space

at a lower quality. If you don't care about lower quality then sure, but you will run into compatibility issues, and since you don't have CPU to transcode, you can potentially be dead in the water if your client can't play it.

5 minutes ago, SpeedBird999 said:

while swapping DVDs and Bluerays in and out and then encoding them requires a lot of personal time in front of the machine

That is fair. but to me it feels like you are cheating yourself.

[xAcid9]

42 minutes ago, SpeedBird999 said:

..furthermore the latest version of Handbrake doesn't allow to take advantage of Nvidia's GPU NVENC encoder for it (i don't know why, after googling it out it seems that it used to be supported bu264 that's no longer the case) meaning much longer trans-coding times (4 or 5 times as much, with my machine R5 3600 Quadro P4000).

Still supported for me. Both h264 and HEVC 

 

As for image quality, you be the judge yourself. 

[SpeedBird999]

38 minutes ago, Takumidesh said:

what does this mean exactly?

 

as it stands, h.265 has less support, and new codecs (av1) are already being released that can perform better than h.265

 

I would argue that an h.264 encode is more future proof as it doesn't require as much dedicated hardware and can easily be decoded by most CPUs with pretty minimal effort.

 

at a lower quality. If you don't care about lower quality then sure, but you will run into compatibility issues, and since you don't have CPU to transcode, you can potentially be dead in the water if your client can't play it.

That is fair. but to me it feels like you are cheating yourself.

I admit my lack of knowledge on the topic, but i though that the idea of progressively newer codecs being developed & introduced was to maintain roughly the same quality while dropping bandwidth and storage requirements. Like the newer tech & algorithm allow the "magic" of same quality with less data.

But yeah, your point about H264 are absolutely valid.

Gonna probably do it that way, thanks.

[SpeedBird999]

23 minutes ago, xAcid9 said:

Still supported for me. Both h264 and HEVC 

 

As for image quality, you be the judge yourself. 

Ok, this wasn't in my handbrake, so i deleted it and re-installed it and now it's there.

What on earth i had installed before i have no idea honestly, i hope it was just an old version or something.

Thanks for the help.

[Takumidesh]

9 minutes ago, SpeedBird999 said:

I admit my lack of knowledge on the topic, but i though that the idea of progressively newer codecs being developed & introduced was to maintain roughly the same quality while dropping bandwidth and storage requirements. Like the newer tech & algorithm allow the "magic" of same quality with less data.

But yeah, your point about H264 are absolutely valid.

Gonna probably do it that way, thanks.

you are right in that you get reduced bitrates with same or similar quality, but nothing is free in this world. It comes at the cost of expensive compute. h.265 requires either fixed function hardware (NVENC) or more complex software implementations.
 

So if your primary limit is your servers compute abilities (raspberry pi) then using more advanced codecs will put more strain on the weakest point of the server. This is fine if your clients are able to decode the codec you are using. The problem comes when the client cannot play it. At that point your server must do an on the fly transcode and the rpi will struggle to keep up or possibly won't be able to do it all.

you can test this by doing a transcode from h.265 -> h.264 on the rpi, is it able to process it faster than 24fps (for movies)?

if not, then you won't be able to watch that video on a client that doesn't support h.265.

 

 

 

NVENC has worse quality because it has less information. The benefit to using a gpu for transcoding is speed, but due to the nature of parallel processing you don't have as much information about the previous and next frames to be processed, so the encoder can't make as informed decisions (for example if this pixel is going from black to white, a software implementation can look ahead and see that and do some processing on the current frame to make that transition look better, a GPU doesn't know that, and therefore has to make a less educated guess) It is a little more complicated than that, but the general idea is there. Encoders actually look at blocks of the image and compare them to see what changes and what needs to be converted on this frame. if the next 25 frames has a 100x100 block that is 100% black, it might decide to something differently compared to rapid flashing colors for example.

[SpeedBird999]

49 minutes ago, Takumidesh said:

you are right in that you get reduced bitrates with same or similar quality, but nothing is free in this world. It comes at the cost of expensive compute. h.265 requires either fixed function hardware (NVENC) or more complex software implementations.
 

So if your primary limit is your servers compute abilities (raspberry pi) then using more advanced codecs will put more strain on the weakest point of the server. This is fine if your clients are able to decode the codec you are using. The problem comes when the client cannot play it. At that point your server must do an on the fly transcode and the rpi will struggle to keep up or possibly won't be able to do it all.

you can test this by doing a transcode from h.265 -> h.264 on the rpi, is it able to process it faster than 24fps (for movies)?

if not, then you won't be able to watch that video on a client that doesn't support h.265.

 

 

 

NVENC has worse quality because it has less information. The benefit to using a gpu for transcoding is speed, but due to the nature of parallel processing you don't have as much information about the previous and next frames to be processed, so the encoder can't make as informed decisions (for example if this pixel is going from black to white, a software implementation can look ahead and see that and do some processing on the current frame to make that transition look better, a GPU doesn't know that, and therefore has to make a less educated guess) It is a little more complicated than that, but the general idea is there. Encoders actually look at blocks of the image and compare them to see what changes and what needs to be converted on this frame. if the next 25 frames has a 100x100 block that is 100% black, it might decide to something differently compared to rapid flashing colors for example.

Very nicely explained. I get it now, as much as in economics there is no such thing as a free lunch.

Thank you very much.