Browser support for .mov video
Asked Answered
D

3

11

I'm trying to display on the web videos (using the HTML5 video tag) emailed directly from an iPhone SE using iOS 12.2. The file extension is .mov, and the codecs used are H.264 and AAC. I'm trying to figure out if I need to convert the videos to another format to achieve cross-browser support for 95% of US browsers.

I looked up support for the Video element on CanIUse , and the sub features tab shows links for more details on the following formats:

I've read that .mov files can use MPEG-4 formats. Is there anything particular about the .mov extension versus the .mp4 extension on the web that affects browser support?

In other words, does the MPEG-4/H.264 table on CanIUse apply to .mov files the same as .mp4 files? Or is there any difference?

Discover answered 16/7, 2019 at 14:58 Comment(2)
What codecs are used for the video and audio formats? Check with a media player (like VLC). Also If lucky, it might work if you rename from file.mov into file.mp4 then test in browsers like desktop & Android too.Loehr
@Loehr control-clicking the file and choosing get info on Mac OS showed Codecs: H.264, AAC. Maybe useful to know about renaming, but I am wondering if it would work on various browsers as is, without renaming either. I don't have an Android or Windows environment to test with, so hoping to find answers here.Discover
O
12

According to https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Containers#quicktime, the Quicktime container format (.mov) is not supported by most modern browsers. However, testing it myself, I do see different results:

Test setup

Video file: a .mov container with a H264 video (codec avc1.640028) inside (exported from Quicktime on macOS)

HTML:

<video width="1280" height="720">
  <source src="lightbulbs-h264.mov" type="video/quicktime">
  No video support.
</video>

Variables:

  • Multiple browsers on multiple OS'es (covering the WebKit, Blink and Gecko engines)
    • macOS 13.2.1
      • Firefox 113.0.1
      • Safari 16.3
      • Chrome 113.0.5672.126
    • Windows 11 (via VirtualBox)
      • Edge 113.0.1774.50
      • Firefox
      • Chrome
    • Android (OxygenOS 13.1)
      • Chrome
  • Multiple type declarations in the source tag.

Live example: https://codesandbox.io/s/happy-platform-nwsg4u?file=/index.html

Results & conclusion

Browser video/quicktime video/mp4 video/mp4; codecs="avc1.640028"
Safari (mac)  ✅
Firefox (mac)  ✅
Chrome (mac)  ❌
Edge (Win)  ❌
Firefox (Win)  ✅
Chrome (Win)  ❌
Chrome (Android)  ❌
Samsung Internet (Android)
UC (Android)  ❌
Opera (Android)  ❌
Edge (Android)  ❌
Firefox (Android)  ✅
Tor Browser (Android)  ✅
Firefox (Linux)  ❌

As you can see, all Blink/Chromium based browsers seem to fail when defining the video source type as video/quicktime.

In conclusion, from this (albeit limited) research, you should be fine if you can ensure that the video files are encoded as H264 video within a .mov container, assuming you use the type video/mp4 for your source tag.

PS: I do not have any iOS devices to test on, but I assume that you can test this yourself.

Orthography answered 25/5, 2023 at 10:1 Comment(4)
Wow! Thanks so much for putting so much effort into this answer! This is excellent.Lopsided
Good job. My additional comment would be too extensive to fit in here, so I integrated it as an addendum into my postLeyes
FYI. For Android I confirm no support for video/quicktime also for the following Blink/Chromium Browsers -- Samsung Internet, UC, Opera and Edge. In contrary and as to expect Firefox (and with that also Tor Browser, when turning off some blockers) does support video/quicktime. Feel free to integrate this in your answer, if you like.Leyes
It works if you use an H264 encoded mov file without setting the video type as well.Cibis
L
2

On .mov files and caniuse.com

The last part of the OP's question has not been answered yet.

In other words, does the MPEG-4/H.264 table on CanIUse apply to .mov files the same as .mp4 files? Or is there any difference?

Taking a look into CanIUse's raw support data we'll find the necessary metadata on the MPEG-4/H.264 codec in the corresponding features-json/mpeg4.json data file, on line 563:

"keywords":"avc,mp4,mpv,mov,aac,h264",

Of course, mov could also be a keyword somewhere else, but when searching the given repository, one will only find it in the features-json/mpeg4.json data file, and correspondingly one time each in the files data.json, fulldata-json/data-1.0.json and fulldata-json/data-2.0.json which are just compositions of all the features-json/ files.

So, yes. The MPEG-4/H.264 table on CanIUse applies to .mov files the same way as to .mp4 files.

Addendum on the browser support for .mov files

Concerning the first question:

I've read that .mov files can use MPEG-4 formats. Is there anything particular about the .mov extension versus the .mp4 extension on the web that affects browser support?

The relation between the .mov container format and the MPEG-4/H.264 codec has already been elucidated in the answer of Gerrit Bertier.

I would like to add, that as e.g. the MDN Web Docs on Video and audio content state:

Each <source> element also has a type attribute. This is optional, but it is advised that you include it. The type attribute contains the MIME type of the file specified by the <source>, and browsers can use the type to immediately skip videos they don't understand. If type isn't included, browsers will load and try to play each file until they find one that works, which obviously takes time and is an unnecessary use of resources.

So, that's a typical case of branch predication.

It seems that Blink/Chromium-browser take the strict approach to read video/quicktime literally, and assume that the .mov file uses the now widely unsupported QuickTime format. On one side, such the overhead for loading a file with a probably unsupported codec is avoided. Alas, on the other side .mov container files using still supported codecs as MPEG-4/H.264 or AVI are excluded. The idea is that one should declare MPEG-4/H.264 files explicitly e.g. as video/mp4, independently of the file extension. If it's a .foo file from the outside, but video/mp4 inside, then just use the proper MIME type and that's it.

However, other browsers like Firefox probably assume -- like caniuse.com -- that the .mov file highly likely uses the MPEG-4/H.264 codec and accept the risk to be mistaken, as there will be probably more hits than fails.

Finally, Safari is Apple's browser. And as the QuickTime codec was introduced by Apple it is still supported by Safari, accepting a video/quicktime container with any supported codec inside.

Leyes answered 28/5, 2023 at 6:7 Comment(1)
Updated with an commenting addendum to the answer of Gerrit BertierLeyes
L
0

Regarding @JesseGavin's query

"The last question in the post is really interesting to me. If anyone can provide more information it would be helpful."

If it's correct to say that this question can be re-asked as:

If an MOV and an MP4 are structurally similar, and can use same audio/video codecs then what makes a browser accept the MP4 but yet also reject an MOV if they are equal?

Then the reasons for that could be varied. I suspect the FYTP is unexpected. You could spend all year exploring the differences. It's better to re-word the problem and then ask as:

"What can we do to an MOV to make it acceptable (as an MP4) to any media player/browser?"

Now it's possible to solve since it could be just one or two simple settings to change, right?

Solution:
The fastest way to convert an MOV into MP4 (where input MOV holds H.264 and AAC) is:

  • (a) Simply rename ".mov" into ".mp4".
  • (b) Change the FTYP atom to say ISOM or MP42.
    (replacing current text qt as found in MOV).
  • (c) Test in any MP4 parser (FFplay? online MP4Box? online MediaInfo?).
    Confirm that players/parsers see the edited MOV as MP4 data.

Below items affect if an MOV can pass for an MP4 to a media player (or web browser):

(1) Renaming: Change file extension from .mov into .mp4.

  • Some software will reject decodable H.264/AAC based on it being inside an unsupported file format.

(2) Picture format: Make sure your H.264 is using YUV 4:2:0 (aka YUV420p)

  • Since H.264 uses YUV420p, assume an non-YUV420p picture format will not work on web browsers. A non-YUV420p must be re-encoded on a pixel level.

(3) Codecs: Use video codec H.264 or H.265 in your MOV. Keep audio codec as AAC format.

  • MOV is a universal container and is not tied to any specific codecs. The player/decoder side needs to simply understand the included a/v codec data and it will play.
    Not all decoders will accept any codec inside MOV.
  • MP4 is a container for MPEG codecs only (eg: MP3, AAC, H264 and H265 etc).
    In other words, an MP4 is really an MOV that specifically holds only MPEG a/v data.

(4) FTYP atom: Change it to ISOM or MP42 (are similar)

  • MOV has FTYP of : qt (with two spaces since it must be four char codes (fourCC)
  • MP4 has FTYP of: avc1, mp41, mp42, isom, dash etc (depends on MP4 type, eg: fragmented).

(5) WIDE atom:

  • MOV has wide atom at top-level (alongside FTYP, MOOV and MDAT and is not a child of these atoms)
  • MP4 does not have a wide atom (except sometimes inside MDAT as a child atom)

    Note: MP4 can have custom named atoms (decoders are to skip any unknown atoms).
    So having one called "wide" will not stop the MP4 itself from playing. It will be assumed to be custom data (example: see WhatsApp's MP4 header)
Loehr answered 30/5, 2023 at 13:19 Comment(1)
@JesseGavin Do you have an MOV that is not working in browser and needs getting advice about?Loehr

© 2022 - 2024 — McMap. All rights reserved.