Possible live streaming regression in 2.4.0

[carlanton]

Environment

• The MPD passes the DASH-IF Conformance Tool on http://dashif.org/conformance.html
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream
• The issue observed is not mentioned on https://github.com/Dash-Industry-Forum/dash.js/wiki/FAQ
• The issue occurs in the latest reference client on http://dashif.org/reference/players/javascript/ and not just on my page

• Link to playable MPD file: https://svt01-a.akamaized.net/u/svt01.mpd
• Dash.js version: 2.4.0
• Browser name/version: Chrome 55.0.2883.95
• OS name/version: OS X 10.11.6

Steps to reproduce

Load the live stream https://svt01-a.akamaized.net/u/svt01.mpd in the latest reference player.

Observed behaviour

This live stream does not start in 2.4.0. Segments are downloaded and the manifest is refreshed, but the stream never starts to play.

The stream works as intended in 2.3.0 and earlier releases.

Console output

dashjs-2.4.0-live.txt

[kgrajek]

I have exact same issue (same log output). Live with DRM works on 2.3.0 but not on 2.4.0.

[nicosang]

it seems that the problem appears with the commit 1657f8f 27th of October. It only occurs whith calculated live edge.

[dsparacio]

Talking a look now. The live edge stuff should all work the same but I must of missed a case in order to simplify live edge as a rule, no need for that, and adding dynamic multiperiod.

[davemevans]

I think the problem is that there is a significant error between the calculated live edge based on the availabilityStartTime and the actual live edge advertised by the SegmentTimeline.

In v2.3 and before this error was determined to be the clientServerTimeShift in TimelineConvertor.onLiveEdgeSearchCompleted and used in all subsequent timeline calculations. This no longer happens, but it probably shouldn't be required.

I see your segments have styp (and sidx) boxes at the end. This is invalid - the styp box must be the first in the box otherwise it may be ignored (which it probably is by most players anyway). Likewise, the sidx should probably be before the moof.

[davemevans]

Forgot to mention that the availabilityStartTime is moving around between 2016-10-26T10:00:51 and 2016-10-26T10:00:53 between refreshes of the manifest. This is invalid according to the DASH specification.

[nicosang]

@bbcrddave I test with the stream http://vm2.dashif.org/livesim-dev/segtimeline_1/testpic_2s/Manifest.mpd. There is also some issues. The stream doesn't start because the call to timelineConverter.setTimeSyncCompleted(true) is not done. So, in the onPlaybackMetaDataLoaded callback, seekToStartTimeOffset is not called.
I have others questions, even if i do the good call. For instance, we will have an expected live edge equals to 1483721762, but the segmentAvailabilityRange parameter will have start=1483722001.015 end=1483722299.015. The Live edge is outside the range. Why do we use current client time to define this segmentAvailabilityRange?

[nicosang]

The last issue was due to a wrong clock time on my PC. :-(

[dsparacio]

@nicosang - and the clock sync failed to solve that? There is suppose to be a bit of code that figures out the local clock offset from NTP server and use that offset for live edge. Maybe a bug there as well?

[davemevans]

and the clock sync failed to solve that?

The problem is that there's no time sync by default when using SegmentTimeline. I recall this was removed because doing so was causing changes to the times requested when we should be trusting the timeline.

Not doing any time sync seems incorrect for me as we should still be paying attention to things like the availabilityStartTime and without syncing to a known good clock it's hard to see how we can calculate whether any segments should be available for example.

I wonder if the whole SegmentTimeline thing needs revisiting ...

[dsparacio]

Ah yes. Kilroy asked for us to remove time sync for seg timeline as it should be useCalculated based on timeline. I agree we should still sync, figure out client offset and apply.

[dsparacio]

wonder if the whole SegmentTimeline thing needs revisiting ...

In Spec or in Dash.js or both. I think the entire way we handle segment formats should be reconsidered lol. But I think we all agree there.

[davemevans]

Adding another live stream which is not playing correctly to the mix: http://irtdashreference-i.akamaihd.net/dash/live/901161/bfs/manifestARD.mpd (from sources.json).

Starts to play but ultimately stalls 😞

[dsparacio]

Hmm I am seeing same on 2.3. This IRT stream has always had issues and failed at some point. Right now I have 2.3 and 2.4 playing side by side with same results. Still no failure yet so Ill keep trying but not sure it is a regression ?

[nitrat7]

same issue see here,
Livestream with segmenttimeline does not run smooth on dash.js 2.4 but 2.3.

http://haidshintn-i.akamaihd.net/dash/live/926080/24test/dash.mpd

See infos here: #1721

[danrossi]

I can confirm the same problem with a dvr based live stream. However if using the akamai one its ok because of the Akamai time server ?

this is ok and starts right away

http://24x7dash-i.akamaihd.net/dash/live/900080/dash-demo/dash.mpd

[danrossi]

I tried a custom time server and it doesn't seem to be loaded using the old method

addUTCTimingSource("urn:mpeg:dash:utc:http-iso:2014",host)

Could that be part of the problem ?

[danrossi]

I just worked out time server will not be used because the manifest has "SegmentTimeline"

I also manage to catch this log.

"SegmentTimeline detected using calculated Live Edge Time "

If I hack this to be disabled it will use the timeserver and start immediately. but the time never updates and stops pretty soon after. In 2.3.0 version it is fine and doesn't stop.

representation.useCalculatedLiveEdgeTime = false;

[dsparacio]

I think this is a red herring @danrossi . We have always had the the same logic for live edge until 2.4 when I changed some stuffs location but not fundamental logic and idea.. I am debugging with the live sim SegTimeline test stream and will update this thread soon.

[danrossi]

@AkamaiDASH even with the 2.3.0 version it seems flakey. The time never updates it still suffers the buffer out when reaching the dvr window also.

I am having similar startup issues with VOD after seeking. Checking if to report that yet.

[dsparacio]

Thanks @danrossi

[danrossi]

I've commented in the right ticket regards to VOD startup times. It seems 2.3.0 is unaffected with that also. So some regressions have crept through. They might be all related ?

[dsparacio]

ScheduleController.js:340 startTime from live edge search 1485287794 1485287794 CORRECT
PlaybackController -> Requesting seek to time: 1485287507.049 INCORRECT

coming from updateTime and calling getActualPresentationTime.

Seems like the seekToStart is not getting fired as mentioned and this is the issue.

[dsparacio]

I can confirm that this stream
http://vm2.dashif.org/livesim-dev/segtimeline_1/testpic_2s/Manifest.mpd
using segment timeline does infact work with tag release of version 2.4.0 but fails in nightly due to changes merged from PR #1658

[dsparacio]

@JontyUsborne Looks like when you did this work in the git history it was before I refactored Dynamic Multiperiod. Then I merged my work and much later we merged your PR which now causes and issue with this stream.
http://vm2.dashif.org/livesim-dev/segtimeline_1/testpic_2s/Manifest.mpd

It will start up but does not seek to the live edge. The liveedge calcs are correct just something in playebackController is now broken post #1658 merge.

Would you mind taking a look so I do not break what you intended to fix?

[dsparacio]

I think I have found the issue.
if ((!isDynamic && streamInfo.isFirst) || timelineConverter.isTimeSyncCompleted()) {

We never did a timeSync on SegTimeline, at least for a few releases, but we did set timelineConverter.isTimeSyncCompleted to true if SegmentTimeline and that is missing. When I add that back in it seems to resolve the issue for this particular stream. Ill test with some of the other stream urls mentioned.

@JontyUsborne I think you are good for now sorry about the back and forth on this

[LloydW93]

We believe this has been fixed in development. Feel free to reopen if this is not the case.

[nitrat7]

Thank you so much!
It's fixed in nightly build, I'm amazed!

Thanks Martin

[dsparacio]

Thank you for confirming @nitrat7 .

[carlanton]

Hi again,

I just tried dash.js nightly build with my stream (https://svt01-a.akamaized.net/u/svt01.mpd) and it works better now, but after a few seconds the stream stops. From Chrome's developer console it looks like the player stops fetching segments. Again, the stream plays fine in 2.3.0.

dash.js-2.4-nightly.txt

[dsparacio]

Ok thanks for reporting @carlanton I am looking now and will update this ticket.

[dsparacio]

Yeah I see this clearly. Look at the time stamps in the player on controlbar. In 2.3 it is expected to be what ever hold back from the DVR live edge. So in 2.3 ther is 14 seconds behind live and you get 10 seconds on playhead time (left side of seek bar) and 24 seconds for DVR window.

In 2.4 however, you get 19:03 which is completely incorrect. Something to do with DVR metrics refactor possible but I need to dig more. Stand by please ;)

[dsparacio]

OK i have tracked it down to this exact commit sha 1657f8f - Looking for a reason and solution now. Thanks

[dsparacio]

@carlanton OK after a bit of searching I figured it out. Your stream is now playing great in 2.4.1. Ill test more to make sure nothing regressive in Multiperiod for live but all the other live sim streams are working as well. I will commit tonight or tomorrow first thing and get a nightly build going. I will also freeze code for 2.4.1 if you can confirm it works.

[nicosang]

@AkamaiDASH , is it the same issue than with the sample http://vm2.dashif.org/livesim-dev/segtimeline_1/testpic_2s/Manifest.mpd? If you play this live stream, and you want to seek near the limit of the dvr window, the stream doesn't restart...

[dsparacio]

@nicosang @carlanton

OK please confirm that PR #1768, which is in RC1 and dev and up on nightly solves the issue for all.

I have tested with the SVT stream and the all live sim streams and akamai streams. All start at proper live edge, can seek and resume. I have only tested on Mac OS Chrome and FF at the moment.

[danrossi]

This stream is broken for me https://svt01-a.akamaized.net/u/svt01.mpd

The time update is very broken, it actually goes back and forth . the duration never changes.

I'm sorry I can possibly email another manifest , but I get no time update and duration never changes.

The startup problem has been fixed as far as I can see.

I will make a report in regards to startup times after VOD seeking, and some possible bitrate switching issues.

[danrossi]

Does anyone have an email or somehow email me, the client I am working with doesn't want the url on public domain so I have to keep their requirements.

The Akamai feed the time updates properly and duration updates properly.

http://24x7dash-i.akamaihd.net/dash/live/900080/dash-demo/dash.mpd

I'll start another ticket with the strange seek update issues with VOD.

[carlanton]

@AkamaiDASH I just tried the stream in dash.js nightly and it works great. Thanks a lot! 💯

[carlanton]

@danrossi I'm not sure if I understand what you mean. Are you talking about the manifest or the player? My stream is a live stream without timeshift/DVR enabled so I suppose the player only shows the current buffer or something. In production we basically hide the player controls to avoid confusing our end users :-)

[danrossi]

I'm talking live DVR. Even if its live the time should be updating. It doesn't for your stream and neither the DVR stream I am testing.

[danrossi]

It's not much to do with DVR but any live stream. The time stops updating for me here with this wowza stream. I'm not sure which manifest is best to choose ?

http://media11.uvault.com/live/2086-828d4b5/liveevent/manifest_mpmpm4sav_mvmvtime.mpd

[danrossi]

Making another ticket up.