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
Assignee: nobody → jyavenard
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.
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.
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?
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
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.