Dash.js: Multiperiod Static VOD Support

[dsilhavy]

Hi,
we are currently refactoring the ad insertion sample sites which rely on multiperiod support. We noticed that there seems to be an issue with multiperiod in general for instance:

1) http://dash.edgesuite.net/dash264/TestCases/5a/1/manifest.mpd
2) http://dash.edgesuite.net/dash264/TestCases/5b/1/manifest.mpd
3) http://dash.edgesuite.net/fokus/adinsertion-samples/xlink/twoperiods.mpd (XLink test vector)

"Uncaught TypeError: Cannot read property 'width' of undefined"

Is this a known bug and the refactoring regarding multiperiod support is still in progress? We were also wondering if there is already a deadline for pull requests in version 2.0?
Thank you and best regards
Daniel

[wilaw]

@dsilhavy - current target date for 2.0 is Jan 29th and there is no PR deadline declared yet. Issues like multi-period playback, segmentTimeline playback etc need to be resolved first and I will push back that release date if they are not solved by the end of this month. We can't sacrifice quality and cannot regress on feature support compared to 1.6.0.

To that end I have assigned this issue to 2.0 milestone. If you can look in to the typeError bug and attempt to resolve multi-period playback, that would be most appreciated.

Cheers

Will

[dsparacio]

Let me take a look at this today and see if we can figure it out. We know about these issues

Seeking back into Previous Period and them seeking or allowing the stream to playing back into next period fails.

addBufferMetrics buffer target and virtual buffer level needs to be looked at.

http://dash.edgesuite.net/dash264/TestCases/5b/1/manifest.mpd#s=80 MultiPeriod does not work in 1.5.1 or 2.0 if start time using fragment args is set.

[dsparacio]

hey @dsilhavy I was able to reproduce it and it use to play over the periods without issue post 2.0 so I need to track the commit that broke this. ;(

[dsparacio]

Hey so it looks like the error is from this commit by @LloydW93 which in turn breaks multiperiod playback in all post commits . Works in code previous to Jan 4th commits..... This is why it is imperative to have test content automated to exercise features outside normal playback.

commit cc64f23d841f480b1ce396380e2cd6df9abd255f
Author: Lloyd Wallis
Date: Mon Jan 4 15:14:29 2016 +0000

[dsparacio]

Uncaught TypeError: Cannot read property 'width' of undefined
checkPortalSize
getTopQualityIndexFor
...
Uncaught TypeError: Cannot read property 'adaptation' of undefined
.... Which cause MP to fail

[LloydW93]

So, https://github.com/bbc/dash.js/commit/3eb47641c5b9d339a7d07297ec07938fe7f3c6b4 fixes the errors mentioned in this issue, and now the player progresses further - it now loads the IS/1st content for the second period. However, it never adds them into the buffer so playback still stalls as before.

[LloydW93]

Appears to be caused by:

Error: Failed to execute 'addSourceBuffer' on 'MediaSource': This MediaSource has reached the limit of SourceBuffer objects it can handle. No additional SourceBuffer objects may be added. at Error (native)
 at Object.createSourceBuffer (dash.no-externals.debug.js:16843:34)
 at Object.createBuffer (dash.no-externals.debug.js:12413:44)
 at Object.createBuffer (dash.no-externals.debug.js:9189:65)
 at createBuffers (dash.no-externals.debug.js:8749:33)
 at initializeMedia (dash.no-externals.debug.js:8696:9)
 at Object.activate (dash.no-externals.debug.js:8413:13)
 at Object.onStreamBufferingCompleted (dash.no-externals.debug.js:15326:20) at dash.no-externals.debug.js:289:30 at Array.forEach (native)

[LloydW93]

Sorry, I've just re-read the part about fragment URLs not working - the mpd now works fine if you watch linearly so I'll PR this change.

[dsparacio]

@LloydW93 We still have an issue I think. http://dash.edgesuite.net/dash264/TestCases/5a/1/manifest.mpd This stream does not play as it did prior to the SHA I posted. Previously I was able to seek to 3:06 and let play into next period. I was able to seek into the next period and I was able to seek back as well al let it play linearly.

What I am seeing now is issues with the time values. It should always say 6:08 for duration and time should never reset to 0:00 and when it crossed the period it should keep incrementing on time not reset to 0. I am seeing all of this at this point.

[dsparacio]

see https://github.com/Dash-Industry-Forum/dash.js/issues/960 -
see https://github.com/Dash-Industry-Forum/dash.js/issues/957
More Multi Period issues

[sandersaares]

We have some multi-period content (also with DRM) in the Axinom test vectors. I have not tested with the latest development branch yet but feel free to make use of it - good multiperiod test data seems hard to come by.

[dsparacio]

@dsilhavy Daniel, started to look at this again. I am noticing that all the test streams fail to even transistion during linear playback in 1.5.1 and 2.0. Are you seeing simalure results. Not sure when this broke in 1.5.1. I know we had this working much better at some point in 2.0 then broke with other PR. I will chase this down and resolve but I am very surprised it is all broken in prior versions. This must be intermittent as I know I have seen this work recently in 1.5.1 and nothing has changed. Just wanted to see if you are seeing same.

http://dash.edgesuite.net/dash264/TestCases/5a/1/manifest.mpd
Linear playback no seeking
2.0 --> Fails and use to work in prior 2.0 commit
1.5.1 --> Fails in 1.5.1
Seek Into period
2.0 --> Fails
1.5.1 --> Fails
Seek out of period
2.0 --> Fails
1.5.1 --> Fails

http://dash.edgesuite.net/dash264/TestCases/5b/1/manifest.mpd
Linear playback no seeking
2.0 --> Fails
1.5.1 --> Fails
Seek Into period
2.0 --> Fails
1.5.1 -->Fails
Seek out of period
2.0 --> Fails
1.5.1 -->Fails

[dsilhavy]

Hi Dan,
just did a quick check in 1.5.1

http://dash.edgesuite.net/dash264/TestCases/5b/1/manifest.mpd
Linear playback no seeking -> Im seeing some weird behavior. Transition from period 0 to period 1 seems to work for me if I don´t seek. Nevertheless transition from period 1 to period 2 is broken. The player seeks to some time around minute 4.
Seek into period --> Fails
Seek out of period --> Fails

I also checked this vector http://dash.edgesuite.net/fokus/adinsertion-samples/xlink/threeperiods.mpd
It has XLink inside but this should not influence the playback.

Linear playback no seeking --> Works for me
Seek Into period --> Works for me
Seek out of period --> Works for me

Can you confirm my results? If thats the case maybe there is something wrong with the other testvectors we are using? Do we need to set a presentationTimeOffset to correct the EPT for period 1 and 2?

[dsparacio]

@dsilhavy thanks for checking. So in 2.0 all fail, in 1.5 I am seeing the xlink MP stream linear playing into second period at time 20S but in FIrefox it fails and in Chrome it does not seek back with my control bar. I need to test with native controls to rule out control issues vs dash.js issue.
Which player did you use, the ref player with custom control bar or something else. Also what browser?

Nonetheless you are right the xlink stream seems to be well formed so I will try to debug with this stream in 2.0 to see what the deal is.

[dsilhavy]

@AkamaiDASH I used the reference player hosted here
http://dashif.org/reference/players/javascript/v1.5.1/samples/dash-if-reference-player/index.html
Switch from period 0 to period 1fails for me in Firefox too, Chrome is working for all three periods.

[sandersaares]

To contribute something to this, I can report that http://media.axprod.net/TestVectors/v6-Clear/MultiPeriod_Manifest_1080p.mpd fails to play the 2nd period using 1.5.1 or the latest development branch version in IE, Chrome, Firefox and Edge.

This video is part of our test data because it is the simplest multi-period video we could think of (just the same content presented twice).

Playback within the first period succeeds but fails both on linear playback and when seeking into the 2nd period. The development branch keeps "doing something" for a while (I see a bunch of log messages scroll by) if you try to seek into the 2nd period but no playback actually takes place.

Furthermore, I note that seeking into the 2nd period produced some exceptions in the development branch build.

With Edge:

SCRIPT5007: Unable to get property 'buffered' of undefined or null reference
BufferController.js (488,9)

With Firefox

InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable dash.all.debug.js:14292:0
TypeError: playbackController is null

[dsparacio]

thanks @sandersaares I partially fixed this stream http://dash.edgesuite.net/fokus/adinsertion-samples/xlink/twoperiods.mpd so not it plays into second period. @dsilhavy Event controller has an issue but just timing with playbackcontroller creation and I fixed that partially as well.

Seeking back in period does not work and other streams do not work yet. Thanks for this new multi period stream - Ill report back soon.

[dsparacio]

I have dug deep down and it is not pretty. There seems to be multiple issues depending on the stream.
If I just focus on linear payback period change:

With the xlink stream it works if I revert this change #1007 and move resetEventController() to reset() from deactivate().

For http://dash.edgesuite.net/dash264/TestCases/5a/1/manifest.mpd

This start time for period 2 (id:1) is correct and we issue s seek and request a fragment but then I get MEDIA_DECODE_ERR.... and it fails to play. This stream also use to work in 1.5.1 and now fails so something has changed in the browser.

for http://dash.edgesuite.net/dash264/TestCases/5b/1/manifest.mpd AND for http://media.axprod.net/TestVectors/v6-Clear/MultiPeriod_Manifest_1080p.mpd

It seems that the stream complete is triggering and we are not transitioning to the new start time no seek being issued or index incrementing .

This being said, and the fact that it broke without code being changed in a public release points to a real need to review the feature implementation and fix all the issues.

We feel that we should release 2.0 and work on this since it is already broken in 1.5.1.

This needs to be a priority in 2.1 and we may need to fix and patch 2..0 with a 2.0.1 release. Either way I just wanted to add these note here and get some feedback.

Some ideas
1 With the simplified fragment load process maybe there is a not a real need for the virtual buffer layer. 2. Have the browser's source buffer implementation progressed enough so that we do not need to tear down the source buffer and rebuild between each period. We need to revisit this idea and test with a simple prototype.

[dsparacio]

More info

Hi,
I'm trying to create multiperiod .mpd files to play with dash.js.
The problem is that the player does a strange seek when it switches period.
Have a look at my mpds:
http://server.pre-view.org/multiperiod/testdash/Manifest.mpd
http://server.pre-view.org/multiperiod/testdash2/Manifest.mpd

When i try to play the first of my mpds using the reference player (tested on 1.5.1 and 1.6.0) it plays fine during the first period (10s long) and then seeks and jumps 10 seconds forward in the seekbar before it continues playing period number two. As long as the stream continues to plays that could be ok. But if i try the next mpd which contains three periods it plays fine the first period and then stops.

The goal is to be able to generate a livestream where not all bitrates will be available during all periods during the stream. Ie, the highest-bitrate stream won't always be available from the server and then it switches to a new period with a lower maxbitrate during that period. Is multi period the wrong way to go? Could it be handled as multibitrate in a single period instead?

/Tim

[dsparacio]

We are moving this issue to milestone 2.1 and will address it first thing.

[dsparacio]

OK two problems preventing Multiperiod from working properly.

1. Event controller reset() was being called between periods but never re-initialize. First I just moved where playbackController was created (cause of null error) from initialize to start method. But then I realized that if we reset and not re-initialize between periods the event controller will not logically work on subsequent periods. So instead of calling reset I call clear in between each periods. This seems proper but I want to run by Daniel - @dsilhavy , Any need to call reset E.g. inlineEvents = {}; inbandEvents = {}; between periods. If we do need to I have a solution for this as well.
2. SEEKING too early after opening a new media source & source buffer-
   
   
   
   • in Canary and Firefox nightly this issue has been resolved so we can seek multiperiod content and it works.
   
   
   • This browser based bug and limitation was suspected because multiperiod all of a sudden stopped working in code that was not changed.
   
   

I tried to find an event or readystate that I could wait for so it will work in today's public browsers but I could not find anything. MediaSource is open and ready and source buffer is ready to append before we ever call seek.

NOTE - this browser issue also affects #s= start time seeking. This also use to work and is not not working due to the same issue.

Both result in a MEDIA_DECODE_ERR and halt playback.

[dsparacio]

Check PR #1199

[dsilhavy]

@AkamaiDASH Hi Dan, thanks for your work here. I can confirm that our XLink test vectors are working in the current dev branch (Chrome). Regarding the EventController I think we need to reset the inline and inband events when transitioning to the next period. The DASH spec says:
" Events shall terminate at the end of a Period even if the start time is after the Period boundary or duration of the event extends beyond the Period boundary".
As I understand you already got a potential fix for that?

[sandersaares]

With current development branch, I get the following results with http://media.axprod.net/TestVectors/v6-Clear/MultiPeriod_Manifest_1080p.mpd

IE11 linear playback fails at 09:26 (well before the end of the first period, sooner than in previous test). Nothing interesting in browser log. A 404 for http://media.axprod.net/TestVectors/v6-Clear/11/0143.m4s is visible in network capture (which is expected as the subtitle stream has 142 segments present and is shorter than the audio/video streams).

IE11 seeking into period 2 fails - content restarts from beginning but progressbar jumps to around 10% and freezes; position indicator freezes on 00:00.

[dsparacio]

@sandersaares when you seek in IE do you get MEDIA_DECODE_ERR. And can both of you confirm playback in nightly of FireFox and Canary?

@dsilhavy then we can call reset but we will need to reinitialize before we start the controller and this is not currently happening on periods switch from stream controller. Would you like me to add the fix or would you like to modify?

[dsparacio]

Adding related issue before closing duplicate. #872

[dsparacio]

Test live stream

This is still the case in 2.0.0 RC_4. I've added http://vm2.dashif.org/livesim/periods_60/testpic_2s/Manifest.mpd as content in the reference player via PR #1157. The reference player stop right before the end of each minute.

[sandersaares]

I note that the failure at 09:26 during linear playback of http://media.axprod.net/TestVectors/v6-Clear/MultiPeriod_Manifest_1080p.mpd also occurs with single-period content, so I will report it as a separate issue (#1211).

This failure does not occur if I turn off the subtitles, so I will retry the multi-period playback without subtitles for now. Everything below is with subtitles turned off.

Linear playback into period 2

Firefox 43, IE 11 and Edge - linear playback just stops at the end of period 1, without starting playback of period 2. Log says "Stream is complete"; no messages that would indicate any obvious error to me.

Chrome 48 - in addition to the above, subtitles get re-enabled and the duration switches to 12:14. The player appears to load the init segments repeatedly - 3 times - and the last segments of all streams, also repeatedly. No further playback occurs.

Seeking into period 2

Firefox 43 - seeking into period 2 resets position to 00:00 and re-enables subtitles (though the sample player UI still says subtitles are off). The presentation I used is the same clip shown twice, so I do not know if it thinks it is playing period 1 or period 2 here (but the position indicator is in period 1).

At the moment of seek, I also see a 404 in the log for a subtitle segment from the end of the video (404 is expected - see #1211 - but it should not be loading any segments from the end at all). I also see it load the last segments of audio and video streams (successfully) for no reason.

IE 11 - same as Firefox, except position gets stuck at 00:00 and seek bar stops moving.

Chrome 48 - same as Firefox, except position gets stuck at seeked-to position, seek bar stops moving and no further playback occurs of any content.

Edge - same as Chrome.

[dsilhavy]

@AkamaiDASH Can you please add the fix you have in mind

[dsparacio]

@sandersaares Thanks for the feedback. It will not work in FF 44 or below and only works in NIghtly. Will not work in Chrome 48 but works in nightly canary build. This we know now. This is 100% due to not being able to seek to soon after the source buffer is open but we are already checking all the checks that it is ready. There are a few bugs in chromium talking about this exact issue. One is resolved saying it is fixed in canary and sure enough MP works in that version.

So what I am trying to do here is see about IE/Edge and if there are dev or nightlys for those browsers we can test. Any leads on that would great.

The seek bar is jsut a side effect of what is going on. When it fails it fails due to a decoder error and we just reset everything and fail. Seek bar just jumps around and fails.

We put a dirty hack of a 1000 mil timeout before we called seek after source buffer in PUBLIC browsers and it works (most the time) but is not a great solution so I want to open this up for ideas.

[dsparacio]

@dsilhavy I will but can you review before I merge. I was just going to call reset and initialize . reset is already being called so just the one extra call should do it. Ill test and submit today.

[ct1n]

We have a test stream with ad insertion using multiperiod at http://31.14.160.192:8000/ah/manifest.mpd
There are at least 2 issues: the player tries to start 4 segments before the last segment but only considers the first period so if the first period has less than 4 segments it fails even if there are very many segments in the entire MPD.
The second issue is that even when it starts playing properly it stops at the end of the first period.

[dsparacio]

we know about the second issue of period transition see this comment

SEEKING too early after opening a new media source & source buffer-

• in Canary and Firefox nightly this issue has been resolved so we can seek multiperiod content and it works.
• This browser based bug and limitation was suspected because multiperiod all of a sudden stopped working in code that was not changed.

But that is a good point of < 4 segments. I assume this is Live content? You would have to set the live delay to 0 but we need to address this in some way. We are just trying to get period transitions to be stable at this point.

[dsparacio]

So it seems that Chrome Version 49.0.2623.75 (64-bit) fixes the browser issues for Chrome on Mac. Test with these two streams and both seek into both sides of the period and playback linearly. @dsilhavy can you verify you see your xlink stream working as expected?

http://dash.edgesuite.net/dash264/TestCases/5a/1/manifest.mpd
http://dash.edgesuite.net/fokus/adinsertion-samples/xlink/twoperiods.mpd

@sandersaares http://media.axprod.net/TestVectors/v6-Clear/MultiPeriod_Manifest_1080p.mpd
I see a few errors so I should be able to debug this stream next but I think it will be easier.

I will test this all on browser stack soon to see what's lacking.

[dsparacio]

@sandersaares want to check maybe you have more insight. I am getting a ton of 404 when I seek within a period or let it play across period. Whats going on with this stream and why are getting so many 404 on content?

[55953] Native video element event: seeked 
[55953] Native video element event: playing 
GET http://media.axprod.net/TestVectors/v6-Clear/11/0183.m4s 404 (Not Found)
  internalLoad  
  load  
  load  
  loadCurrentFragment   
  executeRequest    
  getNextFragment   
  getPlaybackQuality    
  validate  
  onBytesAppended   
  (anonymous function)  
  trigger   
  onAppended    
  (anonymous function)  
  trigger   
  (anonymous function)  
  waitForUpdateEnd  
  (anonymous function)  
  waitForUpdateEnd  
  append    
  appendToBuffer    
  switchInitData    
  onInitFragmentLoaded  
  (anonymous function)  
  trigger   
  onFragmentLoadingCompleted    
  (anonymous function)  
  trigger   
  onLoadingCompleted    
  (anonymous function)  
  trigger   
  report    
  success   
  onload    
[56884] Index for fragmentedText time 732 is 182 
[56884] SegmentTemplate: 728 / 734.006 
[56884] Getting the next request at index: 183 
[56885] SegmentTemplate: 732 / 734.006 
GET http://media.axprod.net/TestVectors/v6-Clear/11/0184.m4s 404 (Not Found)
  internalLoad  
  (anonymous function)  
GET http://media.axprod.net/TestVectors/v6-Clear/11/0184.m4s 404 (Not Found)
  internalLoad  
  load  
  load  
  loadCurrentFragment   
  executeRequest    
  getNextFragment   
  getPlaybackQuality    
  validate  
GET http://media.axprod.net/TestVectors/v6-Clear/11/0183.m4s 404 (Not Found)
  internalLoad  
  (anonymous function)  
GET http://media.axprod.net/TestVectors/v6-Clear/11/0184.m4s 404 (Not Found)
  internalLoad  
  (anonymous function)  
GET http://media.axprod.net/TestVectors/v6-Clear/11/0184.m4s 404 (Not Found)
  internalLoad  
  (anonymous function)  
GET http://media.axprod.net/TestVectors/v6-Clear/11/0183.m4s 404 (Not Found)
  internalLoad  
  (anonymous function)  

[sandersaares]

@AkamaiDASH the 404s are due to the subtitle stream ending early. I am not a fan of representations that end early but it seems to be a fact of life. See #1211 for more context.

[dsparacio]

@sandersaares I found that out a bit later and figure it was related to #1211. Thanks for the confirmation. I'll look at that issue with this stream to see if I can solve it soon.

[dsilhavy]

@dsparacio Chrome Version 49.0.2623.75 (64-bit) on Mac with the XLink content looks great. Seeking and linear playback both works for me.

[ct1n]

For what it's worth, http://31.14.160.192:8000/ah/manifest.mpd doesn't work in either Firefox Nightly for Mac (47.0a1) or Chrome Canary for Mac (51.0.2667.0): when switching periods it gets stuck in a loop with these messages repeated:
[37245] Getting the request for audio time : 37.477006802720545
[37245] SegmentTimeline: 35.015691609976784 / 32.554
[37246] Getting the next request at index: 1

[dsparacio]

@perses is that the first period 4 segment issue causing that and not related necessarily to this thread or are you saying beyond that other issue this stream does not do a period switch?

[ct1n]

It's a separate issue, yes. When it does start properly it has this issue switching periods. I've tried with revision b20e4bc0a22bd86ff626716297ee9e4cf6dcadd6 and no other changes.

[dsparacio]

With PR #1242 you should be able to seek into periods with Firefox. Linear playback falls in FF IE/Edge due to no :"ended" event being fired when a period ends. So the solution should be based around figuring out why this event is not being triggered.

[dsparacio]

Firefox is working better with latest code. As well as safari with some streams. IE and Edge you can still seek but the end event is not triggering the period switch. Still debugging this. Will keep open until all known issues are resolved.

[KarishmaBagga]

@AkamaiDASH if it helps we have run into these issues as well. It is to do with the timeUpdate event being fired differently on different browsers. In chrome it seems to be fixed at 250 ms but in IE and Firefox it seems to be variable based on fps.
As a workaround, we have hard-coded different values of for STREAM_END_THRESHOLD in StreamController.js firefox and IE.

[dsparacio]

Thanks for the insight Karishma. I tired this yesterday and did not change the result fo MP for EDGE/IE but Maybe I went in the wrong direction with that value so Ill try it again. For FF though it seemed to be more of an issue with trying to Vbuffer the next stream’s first segment. Once that was removed it switched periods and switched faster than chrome. Which was a surprise.

Dan

PS Any change with the seek to end issue, last frag stuck? Still very hard for me and others to repro so we moved down in priority but I have made many changes that MAY have had some effect.

From: Karishma Bagga
Reply-To: "Dash-Industry-Forum/dash.js"
Date: Wednesday, April 6, 2016 at 12:41 AM
To: "Dash-Industry-Forum/dash.js"
Cc: Daniel Sparacio
Subject: Re: [Dash-Industry-Forum/dash.js] Multiperiod support (dash.js 2.0) (#1033)

@AkamaiDASHhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_AkamaiDASH&d=CwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=HMIPFyLErj4M8VUwg3x36W02236DJoh_A_hxovpfrCc&m=kL5hKUClNZLPJuHaH7tG0tNECTwPBMNH_D2_hzltHMM&s=kz3szsATdea9CbIp0cIZ8inq_Q_CnHCvrIQtFnOmq5Q&e= if it helps we have run into these issues as well. It is to do with the timeUpdate event being fired differently on different browsers. In chrome it seems to be fixed at 250 ms but in IE and Firefox it seems to be variable based on fps.
As a workaround, we have hard-coded different values of for STREAM_END_THRESHOLD in StreamController.js firefox and IE.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Dash-2DIndustry-2DForum_dash.js_issues_1033-23issuecomment-2D206187065&d=CwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=HMIPFyLErj4M8VUwg3x36W02236DJoh_A_hxovpfrCc&m=kL5hKUClNZLPJuHaH7tG0tNECTwPBMNH_D2_hzltHMM&s=7swP2DpfjHgVyFaG-yD9DQgUIK-ts8UCG52hMZ9-4eA&e=

[dsparacio]

AhHAAA… @KarishmaBagga you are correct!! I went the wrong direction. Moved from .5 to 1 and now MP on end fires in ALL browsers on win and mac!!!

OK - So now the questions is, what is a safe value for all agents as it would be ideal to not detect if possible. But if we need to, we have the utils already so not a big deal.

@KarishmaBagga can I ask what you set these values to?

[dsparacio]

OK I just tested this change on all browswers/os

const STREAM_END_THRESHOLD = .5   ===>  const STREAM_END_THRESHOLD = 1.0;

Seems to resolve the issue without causing other stream end issues but more testing is needed.

One thing I found is that IE detects end now and switches but with this MPD
http://dash.edgesuite.net/dash264/TestCases/5a/1/manifest.mpd
it fails to start without a seek after period switch

[KarishmaBagga]

@AkamaiDASH A value of 1 also failed at times on Firefox. Though it works on IE. We keep it around 1.5 for FF and 1 for IE. We can keep it same for all though

[sandersaares]

While the technical details of the changes here are unclear to me, I am somewhat concerned that a solution based on tweaking magic values may not be very universal. After all, we do not only have differences between browsers but also differences between devices. If a change (or non-change) in some magic value causes dash.js to not work one of the major browsers, what happens on a set-top box with a 2 year old customized copy of Chromium? I would suggest considering an approach that works in all situations, without a dependency on browser specifics.

[KarishmaBagga]

@sandersaares You are not wrong in pointing that out. The magic value may not work tomo or may not work even today for older versions. The fix I suggested was just to get it working in the existing code where we depend on timeupdates from video player to decide when to switch periods.

[dsparacio]

I understand your concern @sandersaares . There was all ready using a magic number, it was just raised a bit. We do need to look at removing it altogether in the future. But with all HTTP streaming techs I have ever worked on, HDS HLS DASH, something like this is always needed to detect end in certain cases. I do not think raising to 1 from .5 will matter much and does solve some MP issues. So for now I opt to keep it until we offer a better solution.

[hanguytv]

Hi everybody,

I'm working on an ads insertion solution that requires multi-periods in dynamic MPD mode. I tried the nightly build reference player with STREAM_END_THRESHOLD to 1.0 but it doesn't work stable with your provided test stream http://vm2.dashif.org/livesim/periods_60/testpic_2s/Manifest.mpd in chrome version 48. Playback stop after two periods.

Can I ask if you plan to fixing this issue as @sandersaares suggested anytime soon? so that I can decide to wait for the fix or looking for other solutions.

Do you have any suggestions for ads insertion in dynamic MPD mode for live streams to work with dash.js?

Thanks!

[dsilhavy]

Hi @hanguytv you can use app based ad insertion as an alternative to the multiperiod approach.Please find an example here http://se-mashup.fokus.fraunhofer.de:8080/adinsertion-sample/index.html

[hanguytv]

Thanks @dsilhavy for the link. That shows multiple period works for static MPD.

I just wonder why the STREAM_END_THRESHOLD doesn't affect this case? what makes handling multi periods differently between dynamic and static MPD?

[dsilhavy]

Hi @hanguytv this demo actually runs on an older version of dash.js, 1.5.1.

[dsparacio]

Most likely a bug. We have not focused on live MP yet. just VOD. The it may be getting the end but having other issue. Just need to debug it and fix it.

[hanguytv]

@AkamaiDASH Thanks for the feedback! Do you have estimation of time to fix the issue? we are being blocked on this in order to implement backend's live ad insertion according to DASHIF IOP v3.2

[dsparacio]

@hanguytv I do not at this time. But I can work with you to resolve it. We are in the middle of 2.1 release so this would be something in 2.2. Have you attempted to locate or debug the issue at all. Any findings?

[dsparacio]

All, I am thinking of closing this issue and opening a new MP Live issue for now. Any objections. I would like to add this to the list of known issues for Live and to release notes for VOD.

[hanguytv]

@AkamaiDASH my colleague is still debugging it but so far no conclusion made yet

[dsparacio]

@hanguytv to be clear, are you using this exact stream to test?
http://vm2.dashif.org/livesim/periods_60/testpic_2s/Manifest.mpd i

I will also use it to test and try to solve. Maybe if it is something super easy we can slip it in...

[hanguytv]

@AkamaiDASH yes, we are using that mpd.

That would be great if you could take a quick look see if it easy to fix. Is it a regression?

The latest thing I heard from my colleague is that it may cause by wrong start offset calculation for dynamic mode. But he didn't conclude anything yet. I'll ask him to update you with more details tomorrow when he gets back to work.

[dsparacio]

well It does keep playing in 1.5.1 but the player always starting a 0 on each period seems very odd for a live stream.

Nonetheless, it is a regression but not from this or last release. As of 2.0 we changed so much that things like this just need to be address and not compared to any 1.x version.

We barely got MP working for most browsers with limited VOD content for 2.1. MP is not a solid feature yet and at this point we have not put tons of effort into it. We are starting to so we will solve this soon.

Things to look at first is are we getting the onEnd event in StreamContorlle.js to init the switch period logic. If so, what is going on during teardown and build of SourceBUffer in the switchStream method.

[dsparacio]

So as expected not getting the event to trigger the period switch. So we need to focus debug efforts why the event is not triggering with live. Maybe that is all that is missing but not sure. I need to understand the live MP use case a bit more.

 function onEnded() {

        let nextStream = getNextStream();

        if (nextStream) {
            switchStream(activeStream, nextStream, NaN);
        }

        flushPlaylistMetrics(nextStream ? PlayList.Trace.END_OF_PERIOD_STOP_REASON : PlayList.Trace.END_OF_CONTENT_STOP_REASON);
    }

[hanguytv]

@AkamaiDASH yes, the 1.51. works with multiple periods in dynamic mpd. However when the player switching periods, the video doesn't switch seamlessly. There is black screen in between, which is a bad experience for end users. What is your take on that issue? is it something quick to fix, just keep playing the next period as the same stream instead of restarting the next stream.

Thank you so much for supporting!

[dsparacio]

@hanguytv - Unfortunately there is no way around the "seam". This is due to the nature of the MSE at this point in time. You can not reuse the same source buffer between periods. It must be closed and re-opened with new stream info. Maybe this will get better in the future but for now that is the limitation.

[dsparacio]

For live issue is timeToend is now not correct. should go from 60 down to 0 , some offset value is not being calculated in at start. It would only work if you started dead on the period change.

60 time to end would only be 60 if you started exactly on period switch should not ALWASY be this.
16.079302072525024 This should be 0 or > stream end value....

[PatrikCarlander]

@AkamaiDASH I have compared period switching between Dashif player and Shaka player. And Shaka player switching period seamlessly. So there has to be a better way to switch period.

[hanguytv]

@AkamaiDASH Great that you found the problem. Do you think it would be able to squeeze the fix in 2.1.0?

For "seamlessly switching", I think switching between contiguous periods' segments should be the same as switching between Representations' segment, doesn't it?

[dsparacio]

@hanguytv - not really like a rep change . if same codec and IDR align it could be. But, what if the new period is single bitrate AVC3 for commercial and other content is not same codec. What if we do not know the codec of new period if it is xlink.

@PatrikCarlander If Shaka is doing it seemless, which would be new for Skaka 2.0 as they did not support MP in 1.x, then most likely there is multiple video elements with multiple source buffers being layered or period codec inspection because they do not support xlink.

Bit of history on the topic.

Codec detection can get complicated with xlink resolutions. Here is a bit of info from the Original Author of MultiPeriod in Dash.js

I am not sure that the player needs that complexity with detecting the same codecs and reusing them if possible. The thing is that in order to be able to reuse the same buffers both audio and video codecs for the next Period have to be the same (which I supposes reduces the possibility of that case). Besides, we can not append these preloaded segments anyway, we should wait till Period finishes. Also I am not sure that it will work at all, because meta data of two Periods could be different. Thus, I see more potential issues than benefits here.

Some more history here.
https://github.com/Dash-Industry-Forum/dash.js/issues/126

Now, this being said I do agree it is not a great experience. To enhance this will be a feature enhancement and something we need to talk as a group and schedule into a release. This is an open source community project. We have bi-weekly meetings to discuss such items.

Maybe you can join this meeting and help out in the implementation if you would like to see this expedited?

Cheers,
Dan

[hanguytv]

@AkamaiDASH Thanks for the insight. I would love to look at how to implement the seamless period switch. However, I mainly work with the backend side and have limited knowledge of javascript and dash.js. So if you point me some entry points that I can start to read the code to understand how it's currently implemented, I could do that after work hours at least. When is 2.1.0 planned to get out?

[hanguytv]

@dsilhavy Did you try the client-based ad-insertion approach with Chromecast? For me, CC crashed when the application initialized two player instances.

[hanguytv]

@dsilhavy it seems Chromecast doesn't support more than one active video pipelines at the same time create-multiple-instances-of-html-video-object. So client-based solution is not possible for Chromecast today and multi-period solution is still much needed

[KarishmaBagga]

@AkamaiDASH I have been debugging a similar issue on Chrome where we don't get onEnded when we call endOfStream on MediaSource. It is intermittent on chrome but things seem to work fine on Firefox though.

[dsparacio]

@KarishmaBagga with multiperiod media specifically? Can you share the stream you see this with?

[KarishmaBagga]

@AkamaiDASH Yes with Live multi-period streams. It is not stream specific and is intermittent for me. I will repro it once more and send you the stream too.

[dsparacio]

@KarishmaBagga Ah for live it is most likely not the stream end threshold but rather the timeToEnd Calculation. It is totally incorrect for MP live.

[KarishmaBagga]

@AkamaiDASH no I actually corrected it at my end and made sure we called endOfStream on media source but don't get onEnded event on Chrome at times.
As another note for MP Live, we right now start from the first period, shouldn't we catch the live edge from the last period and backwards?

[dsparacio]

I am going to close this issue now. If there is issues around VOD Multiperiod content we should open a new clear ticket showing remaining issues. I have also opened a separate ticket for live. I want to keep the two discussions independent. #1360