1143841 - Air Mozilla doesn't use MSE in JW Player 6.12 for HLS streams

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P2)

Description

[Richard A Milewski[:richard]]

In the Video templates for Air Mozilla live events, we set the player to prefer HTML5 over Flash video.

On Firefox Desktop [Dev edition 38 38.0a2 (2015-03-16)] the player still uses Flash video when watching HLS streams.

Documentation on the JW Player website says this is because Firefox has no H.264 codec.

I filed a support request with JW Player asking when the Cisco Open H.264 codec would be supported, their reply said that it wasn't JW Player but the browser that made the decision to use Flash.

Is that the case?   Will future changes to MSE support playing mp4 HLS streams without flash?   ...or is JW Player just finger-pointing?

MSE config settings on my test browser are:

    media.mediasource.enabled         true
    media.mediasource.mp4.enabled     true
    media.mediasource.webm.enabled    false
    media.mediasource.whitelist       false      (although changing this to true does not seem to alter the behavior).

The URL is an Air Mozilla HLS test stream that is usually running 24/7.   If you need it for testing and it isn't running contact [e-mail] or richard on irc.

Comment 1

[Gervase Markham [:gerv]]

> I filed a support request with JW Player asking when the Cisco Open H.264 codec would be supported, 
> their reply said that it wasn't JW Player but the browser that made the decision to use Flash.

That sounds bogus to me!

I don't have Flash installed, and that URL gives me "no playable sources found". So JWPlayer are not using HTML5 even when there's no Flash option.

Gerv

Comment 2

[Mike Taylor [:miketaylr]]

But h264 support != HLS support, right? It seems like JWPlayer is making the right call for now anyways.

Comment 3

[Richard A Milewski[:richard]]

Mike,

Help me understand what's going on.  JW Player at first said it was lack of an H.264 codec that forced us to flash.  Now it's something else.  Is it that we have to have code in the browser to handle fetching and playing the segments in the .m3u8 manifest?

Shouldn't the code in the player be doing that?   Should Air Mozilla be planning to stick with RTMP & Flash until we can do MPEG-DASH natively in Firefox?

I could make a lot of folks (like Gerv) happy if we had a way to make "flashless" Air Mozilla a thing.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

Firefox does not use OpenH264 for decoding and playback of <video>.

Firefox uses platform codecs when available. We have MP4/AAC/H.264 playback on Windows, MacOSX, Linux (if GStreamer + codecs installed), Android, and FirefoxOS.

We don't support playback of HLS, but there are libraries out there that do HLS support in JavaScript using MSE.

Comment 5

[Gervase Markham [:gerv]]

(In reply to Chris Pearce (:cpearce) from comment #4)
> We don't support playback of HLS, but there are libraries out there that do
> HLS support in JavaScript using MSE.

So the answer is that JWPlayer needs to integrate one of these libraries, whereupon their HLS stream can be passed to EME, and it can be played back on versions of Firefox with H.264-video support, as listed by cpearce.

Gerv

Comment 6

[Richard A Milewski[:richard]]

(In reply to Gervase Markham [:gerv] from comment #5)

> So the answer is that JWPlayer needs to integrate one of these libraries,
> whereupon their HLS stream can be passed to EME, and it can be played back
> on versions of Firefox with H.264-video support, as listed by cpearce.
> 

Maybe... but we may not have to wait for JWPlayer to do the integration.  We use their player in a "video template" that we control.  If we can cobble up a player from one of the libraries Chris mentioned we may be able to use that instead of JWPlayer.

 Chris, can you recommend one or more of those JavaScript libraries, and point me in the right direction.

Comment 7

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Yury - is there something we can do with Shumway or your RTMP player?

Comment 8

[Yury Delendik (:yury)]

Anthony,

I saw lots of Flash video players include HLS parsing code, but this type of code produces FLV stream. The Shumway will re-package FLV format into fragmented MP4 to play it using MSE/media tags. But that does not mean we will implement H.264/AAC packets parsing/playback -- the media packets will be re-muxed into MP4 and then will be passed to the platform for playback.

We are planing to look at the media/RTMP playback after Shumway 1.0 release (see also bug 1142562).

Comment 9

[Richard A Milewski[:richard]]

Specifically bug 1102717.

Comment 10

[Chris Peterson [:cpeterson]]

Firefox has a whitelist that currently restricts MSE to YouTube, Netflix, and Dailymotion (though Dailymotion hasn't launched MSE yet). We plan to remove this MSE whitelist in Firefox 42, enabling MSE for any website. We will need to work with JWPlayer to ensure their player works correctly with Firefox's MSE implementation.

Comment 11

[Marco Castelluccio [:marco]]

(In reply to Richard A Milewski[:richard] from comment #6)
>  Chris, can you recommend one or more of those JavaScript libraries, and
> point me in the right direction.

https://github.com/dailymotion/hls.js/

Comment 12

[Richard A Milewski[:richard]]

(In reply to Marco Castelluccio [:marco] from comment #11)
> (In reply to Richard A Milewski[:richard] from comment #6)
> >  Chris, can you recommend one or more of those JavaScript libraries, and
> > point me in the right direction.
> 
> https://github.com/dailymotion/hls.js/

Sadly, we can't use either hls.js, video.js, or TheoPlayer until Akamai fixes their broken streaming media CDN.   We send them HLS streams via HTTPS, and their edge servers send the playlist.m3u8 files to users via HTTPS but the chunklist.m3u8 and mediasegment.ts files via HTTP.

JW Player only works because Firefox can't enforce the mixed media restriction on Flash.

Comment 13

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

(In reply to Richard A Milewski[:richard] from comment #12)
> Sadly, we can't use either hls.js, video.js, or TheoPlayer until Akamai
> fixes their broken streaming media CDN.   We send them HLS streams via
> HTTPS, and their edge servers send the playlist.m3u8 files to users via
> HTTPS but the chunklist.m3u8 and mediasegment.ts files via HTTP.

How do we make that happen?

Comment 14

[Chris Peterson [:cpeterson]]

Richard, can we close this bug about using JW Player and MSE on Air Mozilla?

Comment 15

[Richard A Milewski[:richard]]

Yes.

We've resolved all the issues with Wowza and Akamai.  We can now do end-to-end HLS push processing over HTTPS.

We're using the CLAPPR wrapper around HLS.js.   Works fine on Firefox and Chrome Oddly, there are still issues with both Desktop and Mobile Safari.  We can use JW Player 7 as a fallback for those if necessary.

Comment 16

[Chris Peterson [:cpeterson]]

Thanks. That's great news!

Comment 17

[Jean-Yves Avenard [:jya]]

For the record, the core fix for those videos was bug 1271847. HLS.js generates very weird timestamps.