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 cc64f23
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, bbc@3eb4764 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 #960 -
see #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.

[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.
#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

[ghost]

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

[ghost]

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

[ghost]

@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