In my quest to optimize media serving capabilities, one feature that stood out for testing was Quick Sync, particularly its hardware acceleration potential. I embarked on a comparison between Jellyfin and Emby, evaluating the efficacy of Quick Sync and its impact on system performance.
Read more on the article.
New Lemmy Post: N100 Media Serving Efficiency with Quick Sync (https://lemmyverse.link/lemmy.world/post/14450552)
Tagging: #SelfHosted(Replying in the OP of this thread (NOT THIS BOT!) will appear as a comment in the lemmy discussion.)
I am a FOSS bot. Check my README: https://github.com/db0/lemmy-tagginator/blob/main/README.md
One caveat worth noting is that as soon as subtitle burn-in comes into play (especially at 4K), then you’ll easily hit 100% CPU usage and encounter stutters. It’s less of an issue if you’re using good clients and have control over that, but may be a problem if you’re sharing with your family and they have problematic playback clients.
what is subtitle burn-in?
Subtitles being “burned into” the frames instead of being a separate track, also known as hard-coded sometimes. This enables one to use subtitles on devices which cannot traditionally use them or screw up the display. But this means the server needs to re-encode each and every frame, which is a massive load on the server.
Hardware encoding is really great to have on a server. A lot of the time you wouldn’t even think about its existence in a desktop use case but if you monitor resource metrics on a server you can see how huge of a help it is.
I use an old 7700k for my media server. Took a little stint of configuration to pass the integrated graphics device from the Proxmox hypervisor, into the k8s worker node VM, and then into the Jellyfin pod, but very much worth it. Jellyfin x264 1080p transcoding now takes roughly a third of the CPU resources compared to doing it all in software.