HDR10/Dolby Vision MP4 - Container (mis)identified as MOV?

[forbis]

I just finished using Handbrake to encode a 4K Dolby Vision Profile 8.1 (HDR10) source using the x265 10-bit encoder. The output file format was set to MP4. I placed this file in my Jellyfin library's folder.

When I attempt to play this file in the Jellyfin Web interface (using Chrome 134 on Windows), it forces remuxing stating that the container is not supported - and in "Playback info" the container is identified as "mov". I observe the same behavior in Jellyfin Media Player (v1.12.0 for Windows). Interestingly, when I play on my Android phone using the Jellyfin app, the container is properly displayed as "mp4" in the "Playback info" screen, and is direct playing. Jellyfin server and web version is 10.10.6.

Is this expected/normal behavior? Is there a limitation on Windows to not be able to directly play HDR10/Dolby Vision in MP4 format, or is the container somehow being misidentified as "mov" - and if so, why is it only happening on Windows? Any assistance in further diagnosing this would be greatly appreciated.

Thanks in advance for your input.

[TheDreadPirate]

Can you share your jellyfin and ffmpeg logs via privatebin.net?

And what was the goal of encoding an, I'm assuming, already 4K DV file with Handbrake?

[forbis]

Can you share your jellyfin and ffmpeg logs via privatebin.net?

And what was the goal of encoding an, I'm assuming, already 4K DV file with Handbrake?

The goal is mostly storage conservation and to reduce the need for on-the-fly transcoding for devices with bandwidth restraints. I also convert to MP4 to prevent remuxing MKVs - I would prefer direct play wherever and whenever possible. I was able to get the 44GB source file down to 6.5GB with very little discernible quality loss.

I started my library using the .m4v extension, and it just sort of stuck - but the files are 100% MP4s and I've even tested this using the .mp4 extension to the same results.

I checked the logs, they don't seem to indicate a reason for the remux (other than unsupported container). I've included the logs from around the time I started a stream nonetheless.
Jellyfin log (from ingestion of new file to start of playback) https://privatebin.net/?db33843c120d1320...MJsuaV5Mk3
ffmpeg remux log https://privatebin.net/?ae174c40f8ed67a3...1oWzu2XCiQ

What's strange to me is that even when not in playback, in the "Media info" section the container is listed as "mov". This would lead me to believe it's being identified as such when Jellyfin first detects the file and scans it for metadata. I've also compared the output of ffprobe on these files and compared it to other m4vs I have encoded and the output is identical down to the "Input #0, mov,mp4,m4a,3gp,3g2,mj2", and "major_brand    : mp42". I have to assume Jellyfin server is overriding the container type at some point along the line specifically due to the Dolby Vision content.

[TheDreadPirate]

There has to be an overlap between container and codec support. From what I'm reading, Chrome supports H264 in m4v, but not HEVC? Which is why it is remuxing to MP4, if this is correct.

Not sure about the "MOV" part. m4v is an Apple proprietary implementation of MP4, so maybe that is why?

[theguymadmax]

Not sure about the "MOV" part.  m4v is an Apple proprietary implementation of MP4, so maybe that is why?

When transcoding, any MP4/M4V container appears as MOV in Chrome browsers. However, if transcoding is done in Firefox, it will display as MP4.
https://github.com/jellyfin/jellyfin-web/issues/6539

[forbis]

Not sure about the "MOV" part.  m4v is an Apple proprietary implementation of MP4, so maybe that is why?

When transcoding, any MP4/M4V container appears as MOV in Chrome browsers. However, if transcoding is done in Firefox, it will display as MP4.
https://github.com/jellyfin/jellyfin-web/issues/6539

That github issue is very similar, but one thing that is different in my situation is that the "Media info" screen displays the container as mov, even when not playing. And again, on Android I get direct play and the container is ID'ed as mp4 (https://imgur.com/a/leDgIEs)

There has to be an overlap between container and codec support.  From what I'm reading, Chrome supports H264 in m4v, but not HEVC?  Which is why it is remuxing to MP4, if this is correct.

Not sure about the "MOV" part.  m4v is an Apple proprietary implementation of MP4, so maybe that is why?

I did try with .mp4 extension instead of .m4v, and had the same results. I re-examined ffprobe output for this file and one that is ID'ed properly and did find a difference in "compatible_brands" - "mp42iso2mp41" vs "mp42dby1iso2mp41". This has to play a part in this, right?

Direct plays - Identified as mp4:

Code:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '.\Green Book (2018) - [2160p HDR].m4v':
  Metadata:
    major_brand    : mp42
    minor_version  : 512
    compatible_brands: mp42iso2mp41
    creation_time  : 2025-04-06T04:55:13.000000Z
    title          : Green Book (2018)
    encoder        : HandBrake 1.9.2 2025022300

vs
Remuxes on Chrome - Identified as mov:

Code:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '.\Transformers One (2024) - [2160p HDR].m4v':
  Metadata:
    major_brand    : mp42
    minor_version  : 512
    compatible_brands: mp42dby1iso2mp41
    creation_time  : 2025-04-05T04:37:07.000000Z
    title          : Transformers One (2024)
    encoder        : HandBrake 1.9.2 2025022300

[forbis]

Just as an update, I think the "mov" container might be a red herring, as the github issue linked by theguymadmax alluded to. Apparently ALL of my movies show as "mov" in the Media info view. I am beginning to think that container "misidentification" actually doesn't matter, and what does matter is Chrome is either incapable of displaying DV 8 or Jellyfin thinks it is - which of these is true, I'm not sure.

I'm going to see about enabling more verbose logging to see if I can tell exactly what is triggering the remux. Since I'm a code monkey by day I might also familiarize myself with the source and see if I can glean anything from it.

Further update: Gleaned this from the Jellyfin logs - TranscodeReason=VideoRangeTypeNotSupported

So, Jellyfin is obviously choosing to remux because it believes Chrome cannot play the Dolby Vision content. The "mov" was indeed a red herring and is likely related to the bug outlined in the github issue above. However I am under the impression that DV Profiles 7 and 8 fallback to HDR10 when the player/display is not DV-capable, correct me if I'm wrong here. Why does this not happen automatically and allow me to play direct to the browser?