update of live manifest with large timeShiftBufferDepth is slow

[peyoh]

Hello,
today I clone the latest player.
( Fri Feb 12, 2016)
With attached mpd (502_24h.mpd

501_24h.zip

)

Chrome gets 100% CPU and the tab with player becomes heavly unresponseable. The video "squeezes" also. Debug log shows:

mediakeys.js:48 Using native EME as-is.
2player.js:191 + video/mp4; codecs="avc1.4d001f" is supported
2player.js:191 + video/mp4; codecs="avc1.4d001e" is supported
player.js:191 + audio/mp4; codecs="mp4a.40.2" is supported
player.js:191 + video/mp4; codecs="avc1.4d001e" is supported
player.js:191 + audio/mp4; codecs="mp4a.40.2" is supported
mpd_utils.js:275 SegmentTimeline contains a large gap/overlap. The content may have errors in it. s…a.d…h.mpd.SegmentTimePoint {startTime: 6759155760, duration: 900480, repeat: 298}
mpd_utils.js:275 SegmentTimeline contains a large gap/overlap. The content may have errors in it. s…a.d…h.mpd.SegmentTimePoint {startTime: 7028410800, duration: 900480, repeat: 909}
mpd_utils.js:275 SegmentTimeline contains a large gap/overlap. The content may have errors in it. s…a.d…h.mpd.SegmentTimePoint {startTime: 7847978160, duration: 900480, repeat: 857}
mpd_utils.js:275 SegmentTimeline contains a large gap/overlap. The content may have errors in it. s…a.d…h.mpd.SegmentTimePoint {startTime: 8620605360, duration: 900480, repeat: 2149}
mpd_utils.js:275 SegmentTimeline contains a large gap/overlap. The content may have errors in it. s…a.d…h.mpd.SegmentTimePoint {startTime: 10556641200, duration: 900480, repeat: 2494}
mpd_utils.js:275 SegmentTimeline contains a large gap/overlap. The content may have errors in it. s…a.d…h.mpd.SegmentTimePoint {startTime: 12803446320, duration: 900480, repeat: 289}
mpd_utils.js:275 SegmentTimeline contains a large gap/overlap. The content may have errors in it. s…a.d…h.mpd.SegmentTimePoint {startTime: 13064598960, duration: 900480, repeat: 466}
mpd_utils.js:275 SegmentTimeline contains a large gap/overlap. The content may have errors in it. s…a.d…h.mpd.SegmentTimePoint {startTime: 13485138480, duration: 900480, repeat: 200}
mpd_utils.js:275 SegmentTimeline contains a large gap/overlap. The content may have errors in it. s…a.d…h.mpd.SegmentTimePoint {startTime: 13666150320, duration: 900480, repeat: 446}
live_segment_index.js:240 @availabilityStartTime seems to be inaccurate; some segments

But with shaka-player version from Nov 18 2015,

the same MPD works fine, even the same warnings occurs.
I'm using edash-packager as packetizer.

Please tell me what environment to arrange for debugging.

BRS

[peyoh]

Update,

v.1.6.2 doesn't have this issue.

[joeyparrish]

@peyoh, can you please clarify what you mean when you say that the video "squeezes"? I'm not familiar with that term in this context.

[peyoh]

Sorry for this "term" :),
Video stops and starts again after 3-7 seconds, next read the manifest. Video stops again and starts after 3-5 sec. Read manifest again and video stops again....etc. Will send you a complete debug log. Seems like parsing the manifest overloads the browser.

[peyoh]

@joeyparrish.
I just paste here the text from my email because this can be helpful for somebody:

With larger timeshifts it seems .MPD parsing speed is greatly affected by SegmentTemplate startNumber="17650" parameter:

      <Representation id="2" bandwidth="1701840" codecs="avc1.4d001e" mimeType="video/mp4" sar="64:45" width="640" height="512">
        <SegmentTemplate timescale="90000" initialization="edash-video-512.mp4" media="edash-video-512-$Number$.mp4" startNumber="17650">
          <SegmentTimeline>
            <S t="16786616400" d="950400" r="8173"/>
          </SegmentTimeline>
        </SegmentTemplate>
      </Representation>

As the time goes on, this number increments and the interface starts to be insensitive
and with great delays on events. The CPU load increments also, and on some mobile devices mpd update takes too much time and the playbuffer starts starving.
This I can reproduce on 1.6.2.

But with 1.6.3 even with small timeshift, I'm unable to play video. Seems like manifest ubdate REALLY gets too much time.

[tdrews]

To address one issue: your MPD@timeShiftBufferDepth is ~24 hours. This means the user can seek back ~24 hours in the live stream. Currently the Player will generate SegmentReferences for each ~10 second segment each time the MPD is updated (every 5 seconds), which may become a bottleneck. I suggest reducing your MPD@timeShiftBufferDepth if you don't really need ~24 hours of DVR. That being said, we can probably optimize the MPD update for this style of manifest (e.g., we can avoid creating SegmentReferences when we don't need to, instead of creating them and throwing away duplicates).

[peyoh]

@joeyparrish With timeshiftbufferdepth of 3600 sec, both versions works well.
Just to mention something I think is important.
On the Chrome debug console The time interval between "Updating manifest" and "Manifest updated" is quite different between 1.6.2 and 1.6.3.
On 1.6.2 the inteval is around half a second, but on 1.6.3 is more than a second and increments with larger timeshift interval.

Updating manifest...
live_segment_index.js:240 @availabilityStartTime seems to be inaccurate; some segments may not be available yet: currentPresentationTime 145876.00200009346 latestAvailableSegmentEndTime 145880.25333333333
live_segment_index.js:240 @availabilityStartTime seems to be inaccurate; some segments may not be available yet: currentPresentationTime 145876.00200009346 latestAvailableSegmentEndTime 145882.88
live_segment_index.js:240 @availabilityStartTime seems to be inaccurate; some segments may not be available yet: currentPresentationTime 145876.00200009346 latestAvailableSegmentEndTime 145884.8
live_segment_index.js:240 @availabilityStartTime seems to be inaccurate; some segments may not be available yet: currentPresentationTime 145876.00200009346 latestAvailableSegmentEndTime 145883.84
live_segment_index.js:240 @availabilityStartTime seems to be inaccurate; some segments may not be available yet: currentPresentationTime 145876.00200009346 latestAvailableSegmentEndTime 145881.96266666666
player.js:191 + audio/mp4; codecs="mp4a.40.2" is supported
player.js:191 + video/mp4; codecs="avc1.4d001e" is supported
2player.js:191 + video/mp4; codecs="avc1.4d0015" is supported
player.js:191 + video/mp4; codecs="avc1.4d001e" is supported
manifest_updater.js:397 Updated SegmentIndex 0: 182 -> 182 SegmentReference(s).
manifest_updater.js:397 Updated SegmentIndex 1: 8227 -> 8228 SegmentReference(s).
manifest_updater.js:397 Updated SegmentIndex 2: 8227 -> 8228 SegmentReference(s).
manifest_updater.js:397 Updated SegmentIndex 3: 8227 -> 8228 SegmentReference(s).
manifest_updater.js:397 Updated SegmentIndex 4: 171 -> 172 SegmentReference(s).
player.js:191 + audio/mp4; codecs="mp4a.40.2" is supported
2player.js:191 + video/mp4; codecs="avc1.4d0015" is supported
2player.js:191 + video/mp4; codecs="avc1.4d001e" is supported
stream_video_source.js:476
 Manifest updated!

Thank you.

BRS/
Peyo

[joeyparrish]

Could be a regression, then. We'll look into it for v1.6.4.

[joeyparrish]

@peyoh This should be fixed now. Please try again with the latest from master and confirm.

[peyoh]

Hello,
yes it is fixed. Thank you!

BRS

[joeyparrish]

Great! We'll roll this out in v1.6.4.