Multi period streams with SegmentTemplate not working anymore.

[PatrikCarlander]

Test stream: GPAC "live profile with five periods" or any streams with multi period and SegmentTemplate.
It was this change that break it.
Compare buffering goals to the difference between next segment's start
Change-Id: Ie9fac1b427b631ac467656c15fd8608e12c07efc
commit 0df1ab0

The reason is the new way to calculate bufferAhead in shaka.media.StreamingEngine.prototype.update_ function.
It using getSegmentReferenceNeeded_ method and calculate bufferedAhead
bufferedAhead = needPeriod.startTime + reference.startTime - playheadTime;

This will be next period's start time plus start time of the segment reference from the current period after period end (this segment should not exist).
This will make bufferAhead to big which cause that we fall out of the function that should make the period switch.

It's easy to reproduce and track, play GPAC "live profile with five periods" and it will stop playback before period switch (after 2 min),
if you look at the v2 log for bufferAhead you will see it's to big.

[ismena]

@PatrikCarlander
Thanks for such a detailed repro, we'll look into it.

[ismena]

I'm starting to think this might be a problem with this particular test stream that surfaced after the buffering goal calculation change.

@PatrikCarlander, did you encounter the issue through the "live profile with five periods" stream or do you have a custom stream that behaves the same way? Do you know of any other affected stream (demo or custom)?

[PatrikCarlander]

We have this problem with our regular multi period segmented templated streams. It's not many sample stream of this kind online. I just remove this in Ericsson fork of shaka player. But it would be better if we fix this here. Problem is as a said it get a segment reference after period ended. So if we have 2 min period bufferAhead will be 120 sec and that make us jump out the function.

[baconz]

@PatrikCarlander our multi-period live manifests use SegmentTemplate and work with the latest Shaka.

What we have seen is that if the period start time is not precise enough (rounding issues), you can run into problems like the one you describe.

I think (@ismena correct me if I'm wrong) reference should always be in needPeriod, but this might not hold if your period start times do not match your period durations as calculated by Shaka. As a side note, I think there might be a missing assertion here.

Can you see from the logs whether reference.endTime + period.startTime > nextPeriod.startTime?

[birme]

I can add that I have also had rounding issues with our hls2dash [1] and had to be very careful not to lose any digits when calculating both start times and durations.

[1] https://github.com/Eyevinn/hls-to-dash

[PatrikCarlander]

What is wrong with reference stream GPAC "live profile with five periods"? It worked before this commit.

[baconz]

Sorry about that, I misunderstood -- we use SegmentTemplate + SegmentTimeline with period start times. This manifest uses SegmentTemplates with period durations, and looks like a different issue. Sorry for the confusion!

[ismena]

@PatrikCarlander would you be able to provide a manifest for one of your custom streams that are also affected?

[PatrikCarlander]

The GPAC "live profile with five periods" should not be any problem to test with.
I can send you a privet stream if you send me an mail to patrik.carlander@symbio.com (it's always sensitive to share broadcasters content).

[ismena]

Sounds good. I will reach out to you by email if we need a stream example.

[PatrikCarlander]

I see the same issue with stream
http://lbd.kaltura.com:8001/mapped/playlist-saas.php/disc/1/type/vod/manifest.mpd
from bug #537
We get a bufferedAhead of 90 sec after period switch, which cause that we fall out of the function.

[ismena]

Found it!
The problem wasn't in the new buffering logic, but in the way we were getting a segment reference to calculate it.
(That's why I originally blamed the stream itself thinking it had a 'ghost' segment).

Thanks @PatrikCarlander, having a second example helped.
Let me know if the fix resolves the problem with your custom stream.

[PatrikCarlander]

Thanks. This fix resolve the problem.