Conversation
|
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. |
|
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! |
|
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 think this fixes #867 |
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. |
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.
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.