Bug 941351 (m3u8video)

Handle VIDEO element with M3U8 source

NEW
Unassigned

Status

()

Core
Audio/Video: Playback
P2
normal
4 years ago
13 days ago

People

(Reporter: hallvors, Unassigned)

Tracking

(Depends on: 2 bugs, Blocks: 7 bugs, {feature})

unspecified
feature
Points:
---
Dependency tree / graph
Bug Flags:
webcompat +

Firefox Tracking Flags

(firefox57 wontfix)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Created attachment 8335666 [details]
780379.htm

In bug 780379 we implemented functionality in Firefox for Android to pass M3U8 - files on to some system media player if loaded directly. However, this bug still doesn't handle <video src="foo.m3u8">. As iPhone supports this, we see a significant number of mobile video sites using it.

We need to either implement some sort of playlist support for <video> itself, or make sure the file is passed on to a system player if either JS play() is called or the user clicks the play button. Playlist implementation might make this easier to fix on Fx OS too.
(Reporter)

Updated

4 years ago
Blocks: 804994, 902883
Can we fix this with evangelism instead? We want to limit the formats we support in the media elements, and playlist support can easily be added with a polyfill.

Are the m3u8 here actually Apple HTTP Live Streaming manifests? Supporting those is a bit more complicated and requires the MediaSource extensions, still behind a pref. Once we have that in release, sites can make both HLS and DASH work without any special platform support.
Depends on: 778617
(In reply to Ralph Giles (:rillian) from comment #1)

> Are the m3u8 here actually Apple HTTP Live Streaming manifests?

The file linked from the attachment is an HLS manifest.
The linked m3u8 is indeed an HLS manifest.  It could be supported via MSE in theory (i.e. the spec itself provides sufficient functionality), but I don't believe we have plans to support MPEG-2 TS which is required by HLS.
Ah, good point. I forgot about having to use mpeg-ts. A MediaSource implementation would have to remux as fragmented mp4, or use your proposed unencapsulated API. We would have some overhead compared to native support, but not significant if we can keep the blob slices zero-copy like padenot was talking about.
(Reporter)

Comment 5

4 years ago
We can certainly try to evangelise those sites if we have a good "story" explaining why it would be a better solution to do it differently. If Apple has built more proprietary stuff into this it may be hard to change and thus hard to get sites to change though.
(Reporter)

Comment 6

4 years ago
(Also: I don't know what the difference between normal M3U8 and "Apple streaming manifest" is exactly, but I know that my first attempt at writing a test, based on online information about the M3U8 format, ended up with a test that didn't work on the iPhone either..)
Hallvord - Do you know how prevalent the use of this style of playlist support is on the mobile Web? Can we scrape to find any sites in addition to the two linked as blocked by this bug?
(Reporter)

Updated

4 years ago
Blocks: 935486
(Reporter)

Comment 8

4 years ago
I intend to do some automated research here, but some solutions show just an image with a "play" icon and only create the <VIDEO> tag when the user tries to play the video, so we might not be able to find all instances..
(In reply to Ralph Giles (:rillian) from comment #1)
> Can we fix this with evangelism instead? We want to limit the formats we
> support in the media elements, and playlist support can easily be added with
> a polyfill.
Can you write up how one would go about supporting playlists with polyfill? Having a document we can link to would help evangelism efforts.
(Reporter)

Comment 10

4 years ago
Follow-up question: when I find a site using M3U8 source for <video> elements, how can I check if it's also using the proprietary Apple HLS stuff?
It has to meet the requirements described here: http://tools.ietf.org/html/draft-pantos-http-live-streaming-07#section-3, and then you would look for the new HLS specific tags.  For example, in the Apple example linked above, the top-level m3u8 has a bunch of EXT-X-STREAM-INF entries that identify it as an HLS manifest.
(Reporter)

Updated

4 years ago
Alias: m3u8video
(Reporter)

Updated

4 years ago
Blocks: 945483
(Reporter)

Updated

4 years ago
Blocks: 943584
There is also an interesting discussion about mime type vs sniffing on https://www.w3.org/Bugs/Public/show_bug.cgi?id=11984
See [0] and [1].

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=780379#c58
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=780379#c59
(Reporter)

Updated

4 years ago
Blocks: 955980
(Reporter)

Comment 14

4 years ago
Note: CNN.com sends VIDEO with M3U8 src to devices identifying as Safari on iPhone, and MP4 to those identifying as Android.
(Reporter)

Comment 15

4 years ago
Example of CNN's M3U8 usage:

http://cnnios-f.akamaihd.net/i/cnn/big/world/2014/02/10/tsr-dnt-sciutto-iran-warships.cnn_ios_,150,440,650,1240,.mp4.csmil/master.m3u8?__b__=650

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=638000,RESOLUTION=640x360,CODECS="avc1.66.30, mp4a.40.2"
index_2_av.m3u8?e=b471643725c47acd
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=148000,RESOLUTION=400x224,CODECS="avc1.66.30, mp4a.40.2"
index_0_av.m3u8?e=b471643725c47acd

etc..
That's the strangest m3u I've ever seen.  It's just comments, no actual substance.  Here's an example of basic m3u [0] and extended [1].

[0] https://github.com/nickdesaulniers/javascript-playlist-parser/blob/master/test/mixed.m3u8
[1] https://github.com/nickdesaulniers/javascript-playlist-parser/blob/master/test/extended.m3u

Maybe apple is doing something strange on top of m3u?
Yes. Apple calls this HTTP Live Streaming, and it works like DASH. It's kind-of compatible with m3u, but a player needs to understand the comments to make full use of it.

The comments alternate with relative URIs which give the location of playlist resources describing each stream alternate. "Relative URIs MUST be resolved against the URI of the Playlist file that contains it."

See https://tools.ietf.org/html/draft-pantos-http-live-streaming for more information.

Updated

4 years ago
Blocks: 986895

Updated

4 years ago
Blocks: 957963
FWIW, I think we shouldn't jump to implementing HLS before MSE with MP4 support has been out there for a while and we've seen how that works out. Once Firefox, IE and Chrome all support MSE with MP4, maybe sites wake up and start using DASH.js for non-Safari browsers.
(Reporter)

Updated

3 years ago
OS: Linux → All
Hardware: x86 → All
(Reporter)

Comment 19

3 years ago
NRK.no (basically Norway's BBC) is an example of a site that has three modes: Flash playback for desktop, HTML5 <video> with HLS for iPads - and presumably Android stock browser -, and native apps for iOS and Android. Naturally, none of these work on Firefox OS :-/
KTLA.com's mobile site using HLS for live video: https://github.com/webcompat/web-bugs/issues/389
FWIW - JW Player on Firefox 38 still uses flash to display HLS video with .m3u8 manifests even though FF38 has the Cisco Open H.264 codec.   (bug #1143841)
Blocks: 1143841
(In reply to Richard A Milewski[:richard] from comment #21)
> FWIW - JW Player on Firefox 38 still uses flash to display HLS video with
> .m3u8 manifests even though FF38 has the Cisco Open H.264 codec.   (bug
> #1143841)

We use platform decoders for MP4 playback. OpenH264 is not useful for video playback.
(Reporter)

Updated

2 years ago
Blocks: 1176768
(Reporter)

Updated

2 years ago
Blocks: 1185342
Depends on: 577084
Duplicate of this bug: 861460
Depends on https://webcompat.com/issues/1102
Blocks: 1185334
Depends on https://webcompat.com/issues/389
Component: Audio/Video → Audio/Video: Playback
Depends on: 1208258
(Reporter)

Updated

2 years ago

Updated

2 years ago
Blocks: 940313
Blocks: 1152983
Blocks: 1232236
Blocks: 1247433

Updated

2 years ago

Updated

2 years ago

Updated

2 years ago

Updated

2 years ago

Updated

2 years ago

Updated

2 years ago

Updated

2 years ago

Updated

2 years ago
QA Whiteboard: https://webcompat.com/issues/1949

Updated

2 years ago
QA Whiteboard: https://webcompat.com/issues/1949

Updated

2 years ago

Updated

2 years ago

Updated

2 years ago

Updated

2 years ago

Updated

2 years ago
Depends on: 1243304
Blocks: 1243304
No longer depends on: 1243304

Updated

2 years ago

Updated

2 years ago
Depends on: 1262659
(Reporter)

Comment 26

2 years ago
breaks video on bloomberg.com front page (scroll down for a while to find videos)
(In reply to Hallvord R. M. Steen [:hallvors] from comment #26)
> breaks video on bloomberg.com front page (scroll down for a while to find
> videos)

It this the Ooyala issue? We share a building with Bloomberg in Taipei.
(Reporter)

Comment 28

2 years ago
No, Bloomberg seems to use video.js

Updated

2 years ago

Updated

2 years ago
Duplicate of this bug: 1272534

Updated

a year ago

Comment 30

a year ago
Retiring MP4 video output support on August 1st 2016
https://twittercommunity.com/t/retiring-mp4-video-output-support-on-august-1st-2016/66045

"Beginning August 1, 2016, MP4 URLs will be removed from the payload of Tweets that contain video. Twitter website, iOS and Android applications as well as the Fabric SDK have been updated to solely use adaptive streaming. HLS URLs (.m3u8) will remain unchanged and applications currently using MP4 URLs for video playback should move to using these HLS URLs instead. We are making these changes because adaptive streaming provides a higher quality experience for users by delivering more reliable playback, faster start times, and more efficient data usage across variable network conditions.

One week after MP4 URLs have been removed from the Tweet payload, requests for MP4 videos will no longer be served."
Blocks: 1274864

Updated

a year ago
No longer blocks: 1143841

Comment 31

a year ago
¡Hola!

Subscribing as this breaks Nick Jr on my son's Flame =(

¡Gracias!
Duplicate of this bug: 1281134
tidal.com is using HLS for non-flash users (on desktop): https://github.com/webcompat/web-bugs/issues/2805

Updated

a year ago
yet another one.
https://webcompat.com/issues/2851
Another HLS https://webcompat.com/issues/2854
Another HLS 
https://webcompat.com/issues/2898
Another one:
https://webcompat.com/issues/2902
Another HLS
https://webcompat.com/issues/2931
Another one:
https://webcompat.com/issues/2959
No longer blocks: 1176768
mtv https://webcompat.com/issues/2979
Your M3u8 of the week.
https://webcompat.com/issues/3021
Yet another HLS issue https://webcompat.com/issues/3458

Updated

a year ago
Blocks: 1121921

Comment 43

a year ago
So, is there a plan yet how to move forward with this, or is the plan still "let's wait and maybe websites will switch to our preferred format of MSE+MP4" (which doesn't seem to be the case)?

Can we at least get a simple solution in (non-adaptive) to solve web compat?

How about: parsing these files, finding the stream with the resolution closest to the element's size (from the larger side) and replacing the src with the URI of the stream that belongs to it?
(In reply to Mark Straver from comment #43)
> So, is there a plan yet how to move forward with this, or is the plan still
> "let's wait and maybe websites will switch to our preferred format of
> MSE+MP4" (which doesn't seem to be the case)?
> 
> Can we at least get a simple solution in (non-adaptive) to solve web compat?
> 
> How about: parsing these files, finding the stream with the resolution
> closest to the element's size (from the larger side) and replacing the src
> with the URI of the stream that belongs to it?

There's bug 1286133, not sure when it will ship, maybe 50.

Comment 45

a year ago
(In reply to Marco Castelluccio [:marco] from comment #44)
> There's bug 1286133, not sure when it will ship, maybe 50.

That's just for Android - this is also a desktop problem.
(In reply to Mark Straver from comment #45)
> (In reply to Marco Castelluccio [:marco] from comment #44)
> > There's bug 1286133, not sure when it will ship, maybe 50.
> 
> That's just for Android - this is also a desktop problem.

Is it a widespread problem on desktop?
AFAIK Chrome doesn't support it, Internet Explorer doesn't support it (Edge does, so > Windows 10).

Comment 47

a year ago
(In reply to Marco Castelluccio [:marco] from comment #46)
> Is it a widespread problem on desktop?
> AFAIK Chrome doesn't support it, Internet Explorer doesn't support it (Edge
> does, so > Windows 10).

It's less widespread I think because of MSE+MP4 support on a number of sites/players that would cause issues on Android lacking that delivery method, but that doesn't take away that it's still an issue. See the list linked to this very bug, among others 779, 1703, 1557, 2525, gh 2302, gh 2408 just from a quick scan through what's been reported.

Comment 48

a year ago
I do not use the Flash plugin and I weekly encounter site's that require this for video playback without Flash on desktop.

Updated

a year ago

Updated

11 months ago

Updated

9 months ago
Duplicate of this bug: 902883

Updated

8 months ago

Updated

7 months ago

Updated

7 months ago

Updated

6 months ago

Updated

5 months ago

Updated

5 months ago
Flags: webcompat?
Duplicate of this bug: 1368157

Updated

5 months ago

Comment 51

5 months ago
What is all this telling me?  How do I fix my problem?
(In reply to Charles Moore from comment #51)
> What is all this telling me?  How do I fix my problem?

Sorry for the confusion. This is a complicated issue.

If you are the author of the a site which shows this problem in Firefox, please use HLS.js or another player which supports the MediaSource Extensions API.

If you're not the site author, it's just telling you it's a common problem that we've been working on for a long time.

Comment 53

5 months ago
I am a private individual whose access to the C&TS yard cams became inoperative to me in April.

Updated

4 months ago

Updated

4 months ago
Flags: webcompat? → webcompat+

Updated

3 months ago
Is this why the Apple announcement livestream doesn't work in Firefox?
Flags: needinfo?(giles)
https://www.apple.com/apple-events/september-2017/ for reference.
I believe so, at the end of the page: "Requirements: Live streaming uses Apple’s HTTP Live Streaming (HLS) technology. HLS requires an iPhone, iPad, or iPod touch with Safari on iOS 9.0 or later, a Mac with Safari on macOS v10.11 or later, or a PC with Microsoft Edge on Windows 10. Streaming via Apple TV requires an Apple TV (2nd or 3rd generation) with software 6.2 or later or an Apple TV (4th generation).".
Flags: needinfo?(giles)
(In reply to Joe Hildebrand  [:hildjj] (UTC-6) from comment #54)
> Is this why the Apple announcement livestream doesn't work in Firefox?

Yes.
Probably. The page checks both for HLS support and for Safari/Edge browser names. But Safari is receiving the stream as m3u8, and they usually don't bother to support more open technology.
Keywords: feature
Priority: -- → P2
status-firefox57: --- → wontfix
Just for the record the Livestreaming is not working. but the page now shows the recorded version without issue on Firefox 57.
for https://www.apple.com/apple-events/september-2017/
You need to log in before you can comment on or make changes to this bug.