Closed Bug 1189987 Opened 5 years ago Closed 4 years ago

DASH-IF player plays Air Mozilla DASH live stream for twenty seconds and then stalls

Categories

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

defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox42 --- affected
firefox43 --- affected

People

(Reporter: cpeterson, Assigned: jya)

References

(Blocks 1 open bug)

Details

@ Jean-Yves, can you please take a look at this DASH live stream for the Air Mozilla team? Richard Milewski can keep the stream up until Monday morning (Pacific Time).

He is serving the stream from an old Mac Mini playing a quicktime loop.  DMI output goes to a vBrick 9000 which feeds a Wowza Streaming Engine in SCL3. The stream has no audio, which is expected.

https://mozillalive-a.akamaihd.net/Akamai_Public/ngrp:Nomad-1_all/manifest.mpd

* The DASH-IF player plays the stream for about twenty seconds and then stalls. Sometimes the video turns green.

http://dashif.org/reference/players/javascript/1.4.0/samples/dash-if-reference-player/index.html

In Chrome, the DASH-IF player fails to even play the stream, logging the following errors:

Video Element Error: MEDIA_ERR_DECODE 
Debug.js:115 undefined 
Debug.js:115 [video] stop 
Debug.js:115 [audio] stop 
Debug.js:115 Video Element Error: MEDIA_ERR_SRC_NOT_SUPPORTED 
Debug.js:115 undefined 

* The Bitdash player doesn't display the video in Firefox or Chrome, though I see console log messages about downloading .m4s segments:

http://www.dash-player.com/demo/manifest-test/

* JWPlayer will sometimes render a couple frames in Firefox, but then fails with "Error playing file: URL not found or not accessible." In Chrome, JWPlayer fails with the same error, but never renders any frames.

http://www.jwplayer.com/innovation/roadmap/mpeg-dash/
Flags: needinfo?(jyavenard)
Assignee: nobody → jyavenard
Flags: needinfo?(jyavenard)
No longer depends on: 1191465
Depends on: 1196119
I'd like to get a sample of the mpd and the files associated.

Appears to me that the segment at various resolutions aren't aligned.

It's hard to tell for definite because it continuously change:
however, what we receive is:
audio segment 0: [1251980.558000, 1251992.548000]
audio segment 1: [1252012.558000, 1252020.538000]
that's a 20s gap, this will never play properly and will stall.


video segment 0: [1251980.534000, 1251992.533000]
video segment 1: [1252000.534000, 1252012.536000]
that's a 8s gap. Again, way too much.

With MSE, by default, it is *essential* that segment N of stream X starts almost exactly as segment N of stream Y as the mpd simply tells which streams are where and the dash player will select which segment it will play next.
this is assuming that one segment of a resolution can play in place of another.

The MPD should be able to tell the dash player to be smarter by defining a SegmentTimeline, but I don't think any of the dash.js properly handle that yet.
But now, the mpd file doesn't appear good to me as it defines the SegmentTimeLine of only 5 segments.


But regardless, from DASH:
"<SegmentTimeline> maintains the Adaptation Set’s media timeline, with the start time and duration of each Segment in an Adaptation Set listed in order to provide exact timestamps with variable duration Segments caused by splices, scene detection, dropped Segments, and other live encoding realities. An exact Segment Timeline also enables synchronization of Segment timestamps and URLs between independent encoders and servers operating from the same live feed, and time based synchronization of events, such as ad insertion.  The @t attribute identifies the media timestamp of the first Segment in the Period, which is coincident with UTC @availabilityStartTime, in this case with a single Period starting at zero presentation time.  The duration, timestamps, and timescale of live encoded streams need not be altered for different presentations (e.g. live to VOD) because Segment Timeline supports flexible media timebases and start points. For accurate audio/video synchronization, video must use negative composition offsets to make the first sample presentation time equal the first sample decode time in each Segment (the first sample decode time is stored in each Segment’s ‘tfdt’ box). 
"

Note the last sentence.

The first segment found of the 1280p stream is found at:
https://wowza1.scl3.mozilla.com/Akamai_Public/_definst_/ngrp:Nomad-1_all/chunk_ctvideo_cfm4s_ridp0a0r0_cs112736927520_w959064265_mpd.m4s
starts at 1253892.564000

640p:
https://wowza1.scl3.mozilla.com/Akamai_Public/_definst_/ngrp:Nomad-1_all/chunk_ctvideo_cfm4s_ridp0a0r1_cs112736927520_w959064265_mpd.m4s
starts at 1254160.568000

268s difference with p0a0r0

426p stream starts at 1254432.589000
284p stream starts at 1254512.574000



The reason this fail to load in either chrome or IE is because the certificate at the server is invalid:
 https://wowza1.scl3.mozilla.com/Akamai_Public/_definst_/ngrp:Nomad-1_all/manifest_w1977706907.mpd net::ERR_INSECURE_RESPONSE
For some reasons firefox doesn't care about that (yet it won't let me go on the virgin australia web site because the SSL is supposedly *insecure* sigh).

Now fix the SSL certificates, and it's likely it would work in chrome, because chrome totally ignore the pts and massage things to make it all appear to start at the same time.
The great advantage with that approach is that all invalid streams play great, and all valid streams have A/V sync completely off. And seeing that most streams are wrong. you can see how that flaw turned to their advantage.

Remains the issue on why there's a decoding error in firefox is unclear. When I run those files manually it all plays nicely (example: http://localhost/~jyavenard/public_html/tests/mse_mp4/airmo.html just the video stream)
Peter or Richard, can you please share with Jean-Yves the mpd and media files you are feeding to Wowza? The JW Player problem looks like an encoding issue.
Flags: needinfo?(richard)
Flags: needinfo?(peterbe)
We don't feed either to Wowza.  Wowza includes a transcoder.  We feed the Wowza engine a single RTMP stream and the transcoder generates the manifest files and segmented media files for both HLS and MPEG-DASH at 4 different bitrates.

The Wowza engine can also accept RTSP/RTP and MPEGTS streams as input.
Flags: needinfo?(richard)
Flags: needinfo?(peterbe)
not sure there's much I can do here without further data.

the stall I had was due to massive difference between the audio and video track (Encoding issue)

Chris, is this still P1?
Flags: needinfo?(cpeterson)
I think we can close this bug. The original issue was probably an encoding issue and Air Mozilla is no longer testing the DASH-IF player. They are evaluating some other MSE players, so the original problematic configuration is no longer relevant.
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(cpeterson)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.