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.

[ghost]

@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

[ghost]

@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.

[ghost]

@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.