Skip to content

prefer fmp4 container option#686

Open
dangerchris wants to merge 1 commit intodamontecres:mainfrom
dangerchris:feature/prefer-fmp4-container-option
Open

prefer fmp4 container option#686
dangerchris wants to merge 1 commit intodamontecres:mainfrom
dangerchris:feature/prefer-fmp4-container-option

Conversation

@dangerchris
Copy link
Copy Markdown

Background

Exoplayer has issues handling DV Profile 8 + HDR10+ content on some devices. jellyfin-server already detects and attempts to solve this situation by remuxing content to strip one of the HDR profiles. The remuxing profile uses MPEG-TS segments (Codec.Container.TS) when requested, which requires FFmpeg's hevc_mp4toannexb bitstream filter. That filter produces malformed output when processing DV RPU NAL units at segment boundaries, which causes playback errors and visual artifacts in the video at the segment boundaries in exoplayer.

Proposal

The use of fMP4 segments instead of MPEG-TS doesn't require hevc_mp4toannexb and plays without errors in exoplayer. The server already supports this -- clients must simply request it.

This PR adds a new option to the exoplayer settings to let the client prefer a fMP4 container. This will conditionally set the transcoding profile to have container=Codec.Container.MP4. This is similar to what the jellyfin-web player does.

Screenshot 2026-01-12 at 9 58 34 PM

Testing

I've tested this on a FireTV device and confirmed that with the setting on, the artifacts in the remuxed video stream are gone.

@damontecres
Copy link
Copy Markdown
Owner

Hi, thanks for the contribution! Based on your description, this PR sounds like an attempted workaround for a Jellyfin server and/or ffmpeg issue. Is there a open bug report for this?

In general, I am trying to avoid having a giant list of toggles to override direct playback behavior.

@dangerchris
Copy link
Copy Markdown
Author

I think it's related to https://trac.ffmpeg.org/ticket/7799 or jellyfin/jellyfin#10913, but honesty I'm not sure. It seems like a complex issue involving incompatibilities between jellyfin/hevc_mp4toannexb/exoplayer. Neither of those issues have had any updates in several years.

For simplicity sake I treated it as a exoplayer capability mismatch -- essentially I wanted the client to send "more accurate" capabilities to the server, which causes jellyfin to send a stream it CAN play. This is similar to the purpose of other toggles in the advanced settings. I thought that might be a broad enough use-case that it would be useful to others.

I appreciate what you're saying about the giant list of toggles though. Providing a way for every device to provide accurate capabilities is... challenging at best. That said, it's handy to have the ability to customize the client to the actual capabilities of my device! Perhaps some kind of advanced "capabilities override configuration" would be useful here instead?

If you still think this is better fixed on the jellyfin/ffmpeg side, I can try there and see if/how they want to tackle it. Based on the lack of action on those issues I linked to, I'm not hopeful.

Let me know if you have any other thoughts/ideas. And thanks for making Wholphin. I use it every day and it's great!

@DrHurt
Copy link
Copy Markdown

DrHurt commented Jan 24, 2026

I'm surprised fMP4 isn't the default behaviour. Is there a reason for that?

I know this is an android app, but generally speaking modern formats should be encapsulated in fMP4 as that container can carry more info about the media it carries which some players needs.

So much so that LG webOS and Apple's native AVPlayer do not even support Dolby Vision and Atmos outside of mp4 containers. It's the modern industry standard.

Would there be any drawbacks to actually having this be default behaviour?

@zoro11031
Copy link
Copy Markdown
Contributor

I think this fixes #867

@Nurffe
Copy link
Copy Markdown

Nurffe commented Feb 22, 2026

I'm surprised fMP4 isn't the default behaviour. Is there a reason for that?

I know this is an android app, but generally speaking modern formats should be encapsulated in fMP4 as that container can carry more info about the media it carries which some players needs.

So much so that LG webOS and Apple's native AVPlayer do not even support Dolby Vision and Atmos outside of mp4 containers. It's the modern industry standard.

Would there be any drawbacks to actually having this be default behaviour?

I'm currently trying fmp4 container out on wholphin 0.5.0 + there options to enable it. I see that HDR10+ content on my android shield tv does not play in HDR at all when fmp4 container is used. When TS is used HDR mode works as expected. I'm guessing that HDR10+ metadata is lost when transcode to fmp4 is happening but not for TS

Here is rebased version https://github.com/Nurffe/Wholphin/tree/feature/prefer-fmp4-container-option

I'm still looking trying to figure out why jellyfin is even transcoding with wholphin here in the first place. Same source works without any transcoding on plex.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants