Several pieces of content fail to play under Firefox for various reasons

[wilaw]

Testing /dev 2.0 under Mac OSX 10 and Firefox 43

1. With Envivio test content http://dash.edgesuite.net/envivio/Envivio-dash2/manifest.mpd
   Although segments are downloaded, buffer never fills and playback never commences.
2. Testing with http://dash.edgesuite.net/dash264/TestCases/1a/netflix/exMPD_BIP_TC1.mpd, takes 20s to start even with segments in cache.
3. With live sim stream - http://vm2.dashif.org/livesim-dev/utc_direct-head/testpic_2s/Manifest.mpd - plays for a few seconds and then stops with a "stalling buffer" warning.

[davemevans]

On Win 7:

1 and 2 don't appear to play in 1.6.0 either.
3 WFM

[wilaw]

Adding two more manifests from @sridhard which play under Chrome but not FF 43.0.4 under OSX

https://s3-ap-southeast-1.amazonaws.com/learnyst/schools/99/courses/3040/paid/5880/online/unencryptedDash/VID-20140709-WA0000webTrack.mpd

https://s3-ap-southeast-1.amazonaws.com/learnyst/schools/99/courses/3040/paid/5880/online/unencryptedDash/test2/Averages-IntrowebTrack.mpd

Closing issue #990 so that we can track all of these FF failures under one issue.

[davemevans]

Firefox is reporting MEDIA_ERR_DECODE for both of these streams.

[sridhard]

I can play these streams in chrome. Also I can play the mp4 with same audio/video codec in firefox.

[cpeterso]

@jyavenard, do you know why the .mpd files in this dash.js issue play in Chrome and IE11, but not in Firefox or Safari?

I see the same problem with dash.js, the Bitdash player, and the Shaka Player:

http://dashif.org/reference/players/javascript/v1.6.0/samples/dash-if-reference-player/index.html
http://www.dash-player.com/demo/manifest-test/
http://shaka-player-demo.appspot.com/

[jyavenard]

Stream #1: The fragmented mp4 is invalid ; mediasegment start with ftyp
As per ISO BMFF, ftyp is part of of an initialisation segment.
https://w3c.github.io/media-source/isobmff-byte-stream-format.html
"An ISO BMFF initialization segment is defined in this specification as a single File Type Box (ftyp) followed by a single Movie Box (moov)."
In ISO/IEC 14496-12, 4.3 File Type Box:
"Quantity: Exactly one (but see below)"
See below refers to an exception that for a specific brand type, ftyp may not exist, but that format is incompatible with MSE.

So there can only be ONE file type box per stream.

unfortunately the MSE spec states:
http://w3c.github.io/media-source/index.html#sourcebuffer-segment-parser-loop
"If the beginning of the input buffer indicates the start of an initialization segment, set the append state to PARSING_INIT_SEGMENT."

So the first init segment received, made us go from WAITING_FOR_SEGMENT to PARSING_INIT_SEGMENT and back to WAITING_FOR_SEGMENT

the ftyp indicates the start of an initialization segment, and so we move again to the PARSING_INIT_SEGMENT again, and it now is awaiting for another moov atom which will never come.

Firefox behaviour is entirely per spec.

This bug should be closed as invalid. Bug should be reported to chrome that they accept such invalid data.

[jyavenard]

Stream #2; each representation is a full file, representation 3 is a 39MB file ; the smallest bitrate being a 7.5MB file.
This is a silly test missing the entire point of fragmented mp4 use.
XHR requests aren't cached, you don't really want your media cache to be poisoned by MSE data.
20s test seems appropriate to me to download such big streams.

Firefox won't start playback until the updateend event is fired, that means not until the full appendBuffer has been processed (as per spec).

Having said all that, here playback always starts within 5s, and I'm located in Australia

[wilaw]

@jyavenard - you were correct about stream #1. I got DASH IF to confirm the box structure and reached out to Envivio. They agreed with your assessment and re-encoded the content, which I have mounted here: http://dash.edgesuite.net/envivio/EnvivioDash3/manifest.mpd. This starts and plays on Firefox 43.04 under OSX. I'll issue a PR to erase the older URL from the samples that reference it and replace it with this newer one.

Cheers

Will

[dsparacio]

👍

[dsparacio]

http://dash.edgesuite.net/dash264/TestCases/1a/netflix/exMPD_BIP_TC1.mpd - This stream starts up same in firefox as does in chrome. 2 seconds.

New Envivio Streams plays back perfectly.

http://vm2.dashif.org/livesim-dev/utc_direct-head/testpic_2s/Manifest.mpd - Starts right up and plays well.

Should we close this Issue @wilaw - Please confirm you have same results.

FF v43.0.4 Mac

[wilaw]

Confirmed on FF43.04 OSX10.10.5.

Thanks to everyone for the PRs that resolved these.

Closing as fixed.

[sridhard]

hi,

https://s3-ap-southeast-1.amazonaws.com/learnyst/schools/99/courses/3040/paid/5880/online/unencryptedDash/VID-20140709-WA0000webTrack.mpd

https://s3-ap-southeast-1.amazonaws.com/learnyst/schools/99/courses/3040/paid/5880/online/unencryptedDash/test2/Averages-IntrowebTrack.mpd

Can you please let me know the issue with these streams? I use the castlabs encoder to create mp4 fragment files

[sridhard]

@jyavenard can you please help me in checking what is the issue with the mpd files I shared