about shaka.player play slower than packager generate segment

[FeiCao]

Hi,
I use packager(https://github.com/google/edash-packager) generate the segment, but I found that shaka.player play slower than packager generate segment, for example, packager has generated the number 10000 segment, but shaka.player just play the number 5200 segment. As time go, the span is more and more bigger. Is this correct ?

[tdrews]

Hi,

If you start to package and then start to play shortly after, the player should only be behind 1 segment duration + MPD@minBufferTime (for SegmentTimeline style manifest, which is what edash-packager uses). So, usually just a couple segments (unless your MPD@minBufferTime is quite large).

What is your exact use case? E.g., Starting to package and then starting to play right away? Or starting to package and then starting to play after several minutes or hours?

[joeyparrish]

Also, what version of Shaka Player are you using? Is your client's clock in sync with your server?

[joeyparrish]

@FeiCao, we haven't heard from you in three weeks. Do you still need help with this?

[joeyparrish]

Closing due to inactivity. Please let us know if this is still something you need help with, and I will reopen.

[FeiCao]

@tdrews @joeyparrish thank you, my MPD@minBufferTime is 2s, I use player the live stream. packager and player start working at the same time. The play content always delay about 10s. After player played about 10 hours, the delay between packager and player have increased more than 10s and the video segment number witch player request is not the latest number, the following is my mpd

<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns="urn:mpeg:DASH:schema:MPD:2011" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd" xmlns:cenc="urn:mpeg:cenc:2013" minBufferTime="PT2S" type="dynamic" profiles="urn:mpeg:dash:profile:isoff-live:2011" availabilityStartTime="2016-03-15T04:36:15Z" minimumUpdatePeriod="PT2S" timeShiftBufferDepth="PT10S">
  <Period start="PT0S">
    <AdaptationSet id="0" contentType="video" width="1280" height="960" frameRate="90000/6000" segmentAlignment="true" par="4:3">
      <Representation id="0" bandwidth="2000000" codecs="avc1.4d0020" mimeType="video/mp4" sar="1:1" width="1280" height="960" frameRate="90000/6000">
        <SegmentTemplate timescale="90000" initialization="6765130635932766922//live-video-sd.mp4" media="6765130635932766922//live-video-sd-$Number$.mp4" startNumber="3975">
          <SegmentTimeline>
            <S t="796047396" d="180000" r="5"/>
          </SegmentTimeline>
        </SegmentTemplate>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

[joeyparrish]

@FeiCao, what version of Shaka Player are you using? Is your client's clock in sync with your server?

[FeiCao]

@joeyparrish V1.6.4
sync with my server

[joeyparrish]

@FeiCao are you saying that the gap between player & packager begins at 10s but grows larger over time? Does restarting the player reduce the time again? Can you provide some numbers on how large the gap is and how long it takes to reach that size?

[FeiCao]

@joeyparrish yes, restarting the player reduce the time again, I test it for an hour, the gap between player & packager begins at 6s and it grows to 11s after 1 hour. Another test that the gap between player & packager begins at 6s and it grows to 60s after 18 hours.

[joeyparrish]

We'll try to reproduce and see what we can do to fix it.

[joeyparrish]

@FeiCao, we have been unable to reproduce this drift problem with our own live streams using edash packager. We tested for over 2 hours and found no accumulation of drift at all.

It may be possible that your issue is caused by the timestamps in your content. I recommend that you double-check your source content. Make sure that your timestamps do not jump ahead. Also, make sure you are running the latest version of the packager.

We will continue running our test overnight to verify over a longer period. But so far, with our live content, it appears that Shaka is correctly calculating the live edge and is not accumulating drift.

[joeyparrish]

@FeiCao, we were unable to reproduce after 18 hours of testing.