1263150 - (MPEG-DASH) Adding support for MPEG-DASH

Status: RESOLVED WONTFIX

(Core :: Audio/Video: Playback, enhancement, P5)

Description

[sworddragon2]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160317093216




Expected results:

Since MPEG-DASH is a standard and gets more and more used it would probably a good idea to support it natively (executing document.createElement('video').canPlayType('application/dash+xml'); would then not return an empty string). Currently websites are providing their own solutions to emulate DASH support (for example YouTube by utilizing the Media Source Extensions of the browser).

Comment 1

[Chris Peterson [:cpeterson]]

btw, Edge has native support for both HLS and MPEG-DASH:

https://blogs.windows.com/msedgedev/2015/01/29/simplified-adaptive-video-streaming-announcing-support-for-hls-and-dash-in-windows-10/

Comment 2

[sworddragon2]

I have thought about this and remembered that on Android Firefox got HLS support with bridging and also that Firefox got some time ago support to rely on external codecs (currently with ffmpeg). Actually I'm wondering why MPEG-DASH (and also HLS) don't play in Firefox while having ffmpeg installed. Is there still special support for this bridging required? Would the effort to implement it much more lower than a native solution? This ticket requests native support for MPEG-DASH but if the effort should be much lower maybe a bridged solution could be done first.

Comment 3

[Chris Peterson [:cpeterson]]

Firefox does not support MPEG-DASH natively. The external codecs, like ffmpeg or Windows Media Foundation, are only used for video decoding. Sites should use a JavaScript library like DASH.js or HLS.js that builds on Firefox's standard MSE APIs.

Comment 4

[sworddragon2]

This is the second time you have answered me on such a topic (first at comment #49 at bug 577084 ) with an answer that I think makes no sense against my post. That looks highly suspicious to me but I'm trying to solve this specific issue here:

(In reply to Chris Peterson [:cpeterson] from comment #3)
> Firefox does not support MPEG-DASH natively.

We all here probably know this, otherwise we would not participate in a ticket that mainly claims this missing native support.


(In reply to Chris Peterson [:cpeterson] from comment #3)
> The external codecs, like
> ffmpeg or Windows Media Foundation, are only used for video decoding.

This still leaves the question why we don't use ffmpeg to decode and playback DASH (and eventually HLS) here as long as we don't have native support.

Comment 5

[Chris Peterson [:cpeterson]]

(In reply to sworddragon2 from comment #4)
> (In reply to Chris Peterson [:cpeterson] from comment #3)
> > Firefox does not support MPEG-DASH natively.
> 
> We all here probably know this, otherwise we would not participate in a
> ticket that mainly claims this missing native support.

When I said Firefox does not support MPEG-DASH "natively", I meant that Firefox does not expose MPEG-DASH or HLS support to web content in the <video> element like Edge does [1]. That's what this bug is about. I didn't mean "native" to differentiate between code in Firefox itself and third-party libraries.

Firefox's lack of MPEG-DASH and HLS support is a design decision, for architectural and licensing reasons. MPEG-DASH and HLS have licensing issues and the MSE API is the streaming media standard that desktop browsers are converging on. Both MPEG-DASH and HLS can be built on top of MSE. There is little user benefit to implementing MPEG-DASH or HLS in addition to MSE.

[1] https://blogs.windows.com/msedgedev/2015/01/29/simplified-adaptive-video-streaming-announcing-support-for-hls-and-dash-in-windows-10/

> (In reply to Chris Peterson [:cpeterson] from comment #3)
> > The external codecs, like
> > ffmpeg or Windows Media Foundation, are only used for video decoding.
> 
> This still leaves the question why we don't use ffmpeg to decode and
> playback DASH (and eventually HLS) here as long as we don't have native
> support.

Does ffmpeg support streaming of MPEG-DASH and HLS?

Comment 6

[sworddragon2]

Ah, so the best we will probably get seen as native will be MPEG-DASH/HLS support via third party capabilities?


(In reply to Chris Peterson [:cpeterson] from comment #5)
> Does ffmpeg support streaming of MPEG-DASH and HLS?

As far as I can see demuxing support (marked with D) for both formats is available:

sworddragon@ubuntu:~$ ffmpeg -formats 2>&1 | grep -E 'dash|hls'
  E dash            DASH Muxer
  E hls             Apple HTTP Live Streaming
 D  hls,applehttp   Apple HTTP Live Streaming
 DE webm_dash_manifest WebM DASH Manifest

Comment 7

[sworddragon2]

(In reply to Chris Peterson [:cpeterson] from comment #5)
> That's what this bug is about. I didn't
> mean "native" to differentiate between code in Firefox itself and
> third-party libraries.

At the time I have created this ticket I have indeed thought on built-in code with being native. But at the end it shouldn't matter if we get built-in support with own code or non-built-in support with relying on external capabilities like FFmpeg. I'm fine with any of both variants (as probably the most users will be) and both variants would technically be native if I'm not wrong (and H.264 support relies already on external capabilities so extending it this way should be just fine).


But on actually thinking about this ticket again:

(In reply to Chris Peterson [:cpeterson] from comment #5)
> When I said Firefox does not support MPEG-DASH "natively", I meant that
> Firefox does not expose MPEG-DASH or HLS support to web content in the
> <video> element like Edge does [1].

(In reply to Chris Peterson [:cpeterson] from comment #5)
> Firefox's lack of MPEG-DASH and HLS support is a design decision, for
> architectural and licensing reasons. MPEG-DASH and HLS have licensing issues

So Firefox is basically capable of forwarding to external codecs like it does already with some via FFmpeg but HLS and MPEG-DASH are just suppressed?

What are the architectural reasons you are pointing to? Eventually lack of support by external means (are the FFmpeg capabilities I have posted in comment #6 enough? Does the Windows Media Foundation provide suitable support for HLS and/or MPEG-DASH?)?

Are there really licensing issues if we do this by external means like FFmpeg or the Windows Media Foundation? If yes I'm wondering why H.264 is supported (even without GMP-plugins).


Not that the actual implementation cost for mainly MPEG-DASH (and eventual other important formats like HLS) would be low and other things are the problem which might be more or less easily solvable.

Comment 8

[Chris Peterson [:cpeterson]]

(In reply to sworddragon2 from comment #7) 
> What are the architectural reasons you are pointing to? Eventually lack of
> support by external means (are the FFmpeg capabilities I have posted in
> comment #6 enough? Does the Windows Media Foundation provide suitable
> support for HLS and/or MPEG-DASH?)?

We currently have no plans to support HLS or MPEG-DASH directly in Firefox, even using external libraries. Implementing HLS or MPEG-DASH in Firefox would duplicate functionality of MSE, possibly expose Mozilla or its users to patent licensing issues, and would further entrench the non-free HLS and MPEG-DASH standards in the Web platform.

While Edge supports HLS and MPEG-DASH on desktop, AFAIK Chrome doesn't support HLS on desktop and neither Chrome nor Safari support MPEG-DASH. So, unlike H.264, there is no clear consensus of support across browsers.

> Are there really licensing issues if we do this by external means like
> FFmpeg or the Windows Media Foundation? If yes I'm wondering why H.264 is
> supported (even without GMP-plugins).

H.264 is an unfortunate reality of video on the Web, but video streaming services are moving VP9 and AOM's AV1 codecs. H.264 polyfills using canvas exist but they can't take advantage of GPU acceleration and possibly expose the website serving the polyfill to licensing issues. HLS and MPEG-DASH, on the other hand, can be implemented on top of MSE using JavaScript polyfills like HLS.js or DASH.js.

Comment 9

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 10

[Dennis Schubert [:denschub]]

I see no reason why this should be closed as wontfix. If someone thinks this should be closed, then please provide a reason instead of just closing it without a comment.

Comment 11

[sworddragon2]

@:cpeterson
On rereading this a bit my comment sounds quite a bit harsh towards you but after this long time I forgot most of the context and what jumanji was going on back then. If this was the case then I'm sorry.

For this specific bug I have no strong opinion anymore myself as I did not encounter MPEG-DASH for a very long time and on doing a fast search it seems no major webbrowser (desktop and mobile) except pre-Chromium Edge on desktop did ever support MPEG-DASH. I see the bug linked above where an user enocountered a non-polyfill MPEG-DASH video which fails then but he also mentions Chrome on mobile seems to work fine (unless the site uses something else for Chrome it might be the opposite of what I checked so take that with care).

Also I'm updating the title slightly to reflect better what might be more intended.

Comment 12

[Dennis Schubert [:denschub]]

Turns out that WONTFIX is actually the right state, we deliberately unshipped it in bug 935349.