and a general overall reduction in quality. It took like 2.5 months of non stop work, ryzen 9 5900x and an i7-8700k, nearly 24/7. I re-encoded all my h.264 movies (around 800) into h.265, not from scratch, but from the h.264 encode. 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.įor context, i actually did all this, so this is based in my experience. Why not re rip everything from scratch then? re-encoding always results in worse quality.Ĭonverting from lossy A to lossy B is very time consuming, energy hungry, and will always result in worse than just encode from the rip. 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). Thanks everybody.Ĭurrently my library is all over the place. If you could help me, that would be much appreciated. 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)? 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.Īlso, 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. 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). 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. 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).Īnd here are my doubts (I'm kind of new to this all video trans-coding world). 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. 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. 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). 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |