0

Using the server-side Node code from here, but for src="data:..." I use fileSystem.readFile(). For troubleshooting/testing, can also use the video in the link on that post. It doesn't actually matter what file I use; none work.

I recently started experimenting with HTML5 video. Everything works correctly on Chrome and Firefox, but Safari has been broken for a few days and I couldn't figure out why until I took some time to look closely at the tags.

I'm using this to stream content into the page in chunks:

<video width="800" height="600" autoplay controls>
    <source src="/file.mp4" type="video/mp4;base64">
    Not supported.
</video>

It wasn't until I tried this:

<video width="800" height="600" autoplay controls>
    <source src="data:video/mp4;base64,(Data)">
</video>

That I noticed the problem. After all, how can you go wrong when embedding the entire file?

As it turns out, Safari automatically turns the second one into this:

<video width="800" height="600" autoplay controls>
    <source src="data:video/mp4,video;base64,(Data)">
</video>

I decided to drop the video from my folder into Safari to see the markup it created, and I found something curious: src was in the <video> tag instead of in its own source tag.

For kicks I changed the src tag in the video tag to match the <source> tag and the issue persisted, but instead of a blank white box, it was a black box with a Play button with a diagonal line through it. This suggests that for some reason, Safari doesn't pay attention to <source> tags, while other browsers do.

This was a more concerning issue when I discovered even if the src of the <video> is broken (By having a broken src="data:..."), it still won't check to see if there's a compatible <source>. What's really interesting is that it was paying attention to <source> a few days ago.

Since the <video>'s src had the same issue (,video), I removed the ,video by editing in the dev console and it worked exactly as it should. I attempted to put data:base64;video/mp4, but the issue persisted.

A few other things I tried included removing video/mp4;base64, from the tag entirely, which broke it on all browsers. I put video/mp4;base64 into the type parameter both in the <video> and <source> tags, and it seems those are ignored when the src is data:.

Eventually I tried an image, since those are much shorter load times, and found the same issue: Safari automatically adds ,image to embedded images.

Linked images (<img src="/file.png">) work fine with type="image/png;base64" -- and don't add ,image, while linked videos (<video src="/file.mp4">) doesn't work (And adds ,video).

I thought perhaps this could have something to do with my system not taking byte range into account yet (Per this post)... though this same video, streamed with the exact same code, worked flawlessly the first day I tried it (Call it a week ago).

To make sure I wasn't just missing something, I re-enabled the old snippet (Had a backup) just to see if it'd work that way. No dice.

Although removing ,video and ,image manually works for data: sources, it doesn't work for file sources, as even editing it manually won't cause Safari to re-request the file (When you manually edit data:, you can visibly see it reload the player).

For kicks I tried a couple other thoughts: type="video,mp4" and mp4,video, and the equivalent for src="data:...", all of which also work fine on other browsers, but fail (With an added ,video to the end) on Safari.

For a brief recap:

  • Video, whether src="file" or src="data:..." becomes broken by Safari's automatic addition of ,video in either src="data:..." or src="file" type="...".

  • Images break if src="data:..." but not if src="file".

  • Manual removal of ,image or ,video from a src="data:..." works.

  • Manual removal of ,video from a src="file" doesn't work.

  • Video and image both worked fine ~ a week ago with the same (And similar) code.

  • Video and image currently work on Chrome and Firefox.

Anyone aware of what could cause ,image and ,video to show up, and/or how to prevent it?

  • Not looking for an external module to work around the problem. Wondering what's causing it and how to prevent it.
Drake M.
  • 250
  • 2
  • 16
  • That's a bunch of text, and I'm only at the third paragraph, but `type="video/mp4;base64"` is invalid. `"base64"` has nothing to do with any MIME type. – Kaiido Jan 17 '18 at 05:06
  • @Kaiido I'm wondering if it has something to do with the base64, but it should still be valid in src: http://www.iandevlin.com/blog/2012/09/html5/html5-media-and-data-uri/ https://stackoverflow.com/questions/4409445/base64-png-data-to-html5-canvas – Drake M. Jan 17 '18 at 05:12
  • Yes it must be there in the dataURI, since it is part of the dataURI header, but not of the MIMEType, which should be in the `type` attribute. But anyway, this is probably not your problem. As to why this `,video` comes in, I have no idea, maybe indeed your gzip thing. But why are you even trying to send your video this way? Can't you just send it normally (as range requests) instead of sending the whole file in one go every time? – Kaiido Jan 17 '18 at 05:23
  • @Kaiido As stated in the post, it doesn't matter which way I try. It fails both ways on Safari and succeeds either way on Chrome and Firefox. I prefer sending chunks; It's faster and lighter, but I'm loading everything in at once to debug what's happening. If I send a request for a file, it means it'll stream it in. If I use src:data, I'm loading it all instantly. In that, the same issue exists either way. For the GZip bit, that's a separate issue -- in this post I'm not zipping anything before trying to send it. The link was more or less to show the server-side script and offer a test video. – Drake M. Jan 17 '18 at 05:30

0 Answers0