4

FAQ

gnattu edited this page 2025-09-14 10:40:43 +08:00

Table of Contents

• Why use Jellyfin‑FFmpeg instead of upstream FFmpeg?
• Will this affect playback quality?
• Is it faster?
• What platforms benefit most?
• Do you upstream your changes?
• Are there downsides?

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Why use Jellyfin‑FFmpeg instead of upstream FFmpeg?

• It reduces real‑world playback issues in Jellyfin, especially with HDR/Dolby Vision content, HLS/fMP4/MPEG‑TS streaming, and hardware acceleration.
• It includes targeted fixes and features (many hardware‑specific) that upstream may not prioritize or review quickly.

Will this affect playback quality?

• Yes, typically positively: improved tone mapping, better HDR metadata handling, and fewer container/muxing edge cases help clients playback.

Is it faster?

• Often. We include SIMD‑optimized software filters and tuned hardware paths (reduced copies/interop, smarter defaults) that improve throughput and latency.

What platforms benefit most?

• NVIDIA, Intel, AMD, Apple Silicon Macs, and Rockchip RK3588 SBCs see the most improvements due to interop, driver workarounds, and added filters.

Do you upstream your changes?

• Bug fixes: yes, when feasible. Feature patches are harder to upstream due to different priorities and review bandwidth; see Upstreaming.

Are there downsides?

• Update frequency: due to limited human power, we usually lag upstream FFmpeg by a few months. If you need bleeding‑edge upstream features immediately, they might not be available here yet.
• If your workloads are simple and upstream FFmpeg already works, you may not notice a difference.
• Our focus is Jellyfin server use cases over legacy build environments; extremely old compilers/OS/CPUs may not be a priority.