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.
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.
(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.
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.
(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?
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.
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.
There is also an interesting discussion about mime type vs sniffing on https://www.w3.org/Bugs/Public/show_bug.cgi?id=11984
Note: CNN.com sends VIDEO with M3U8 src to devices identifying as Safari on iPhone, and MP4 to those identifying as Android.
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..
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.
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.
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)
(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.
4 years ago
Depends on: HLS
Component: Audio/Video → Audio/Video: Playback
See Also: → https://webcompat.com/issues/1732
QA Whiteboard: https://webcompat.com/issues/1949
See Also: → https://webcompat.com/issues/1949
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.
No, Bloomberg seems to use video.js
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."
¡Hola! Subscribing as this breaks Nick Jr on my son's Flame =( ¡Gracias!
tidal.com is using HLS for non-flash users (on desktop): https://github.com/webcompat/web-bugs/issues/2805
Your M3u8 of the week. https://webcompat.com/issues/3021
See Also: → https://webcompat.com/issues/3021
Yet another HLS issue https://webcompat.com/issues/3458
See Also: → https://webcompat.com/issues/3458
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.
(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).
(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.
I do not use the Flash plugin and I weekly encounter site's that require this for video playback without Flash on desktop.
See Also: → https://webcompat.com/issues/4261
See Also: → https://webcompat.com/issues/4921
See Also: → https://webcompat.com/issues/5079
See Also: → https://webcompat.com/issues/5324
See Also: → https://webcompat.com/issues/6048
2 years ago
Duplicate of this bug: 1368157
See Also: → https://webcompat.com/issues/7258
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.
I am a private individual whose access to the C&TS yard cams became inoperative to me in April.
See Also: → https://webcompat.com/issues/7422
See Also: → https://webcompat.com/issues/7663
Is this why the Apple announcement livestream doesn't work in Firefox?
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).".
(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.
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/
I recommend we close this now. I've gone through all the related bugs, and all except 8 are working as expected (of ~120 in this bug and elsewhere). Will file follow up bugs.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.