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

[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

[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