Multi-period with timeline playback issue

[vto5623]

Hi,

Shaka Player complains about this manifest and does not download any segment: http://vm2.dashif.org/livesim-dev/utc_direct/segtimeline_1/periods_30/testpic_6s/multiaudio.mpd

When it was trying to play the following snapshot of the stream (multiaudio.txt), it reported the following debug logs (shaka.txt).

However, if you try with the following url, it plays fine: http://vm2.dashif.org/livesim-dev/utc_direct/segtimeline_1/testpic_6s/multiaudio.mpd.

As I believe that the only difference between the two streams is multi-periodicity, there may be an issue in the generated manifest using "periods_30".

[TobbeEdgeware]

Hmm. Multiperiod with SegmentTimeLine is not much tested, so I need to dig a bit deeper to see what's going on.

[nmsguru]

Was this issue ever addressed? I'm still not able to play this stream properly in Shaka player. It would start but freezes after awhile - https://vm2.dashif.org/livesim/segtimeline_1/periods_30/testpic_2s/Manifest.mpd

If I tried to play this stream - https://vm2.dashif.org/livesim/segtimeline_1/periods_30/testpic_6s/Manifest.mpd - it freezes even faster.

It will play this stream - https://vm2.dashif.org/livesim/segtimeline_1/testpic_6s/Manifest.mpd.

I tried other players such as Chrome dash.js player but that also fails to play the multiperiod segment timeline stream.

I did notice a possible issue - when generating multi-period streams with segment timeline, the last period in the stream is sometime empty. It looks like the server creates a new period when the last period is about 50% filled up. I thought maybe that was the cause of the issue, so I made a change to the code to not generate that empty period (I made the change in generate_period_data to iterate from first_period_nr to this_period_nr instead). This will not generate the empty period in this case, but that didn't fix the problem.

[nmsguru]

Just in case anyone want to investigate further, to change the server to not generate the last empty period, I modify the generate_period_data function in dash_proxy.py and check to see if timeline is being generated. If so I set the last_period_nr to be this_period_nr. This will cause it to not generate the last empty period.

    if cfg.seg_timeline or cfg.seg_timeline_nr:
        last_period_nr = this_period_nr
    else:
        last_period_nr = (now + half_period_duration) // period_duration

[nmsguru]

I found that if you include start_-6 as an option along with the fix to prevent empty period from forming, then it will playback in Shaka player but with some errors during the transition to a new period.

[nmsguru]

The stream however doesn't play in dashif.js. It plays for a while but the buffer will run out and the player will stop. It may restart after awhile.

It also won't play in exoplayer or in chrome dash.js player.

[nmsguru]

I think I found the problem. The server is incorrectly interpreting the "S@r" parameter I think.

Here is an example:
<SegmentTemplate initialization="$RepresentationID$/init.mp4" media="$RepresentationID$/t$Time$.m4s" presentationTimeOffset="140176801800000" timescale="90000"> <SegmentTimeline> <S d="540000" r="30" t="140176801260000" /> </SegmentTimeline> </SegmentTemplate>

I ran with "periods_20" which should create 180 seconds periods. The timeline above set r=30 which is actually repeating the segment 31 times so the timeline it generates is actually 186 seconds. But the Period@start for this period minus the Period@start for the previous period is 180 second so the code is trying to generate 180 seconds periods but is generating 186 seconds worth of times in the segment timeline.

[nmsguru]

That's not quite right. R is just incorrect for the last segment in a period? Looks like r is adjusted by 1 when it is the last segment in a timeline but not when it is the last segment in a period?