Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update of live manifest with large timeShiftBufferDepth is slow #288

Closed
peyoh opened this issue Feb 19, 2016 · 10 comments
Closed

update of live manifest with large timeShiftBufferDepth is slow #288

peyoh opened this issue Feb 19, 2016 · 10 comments
Assignees
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly

Comments

@peyoh
Copy link

peyoh commented Feb 19, 2016

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
Copy link
Author

peyoh commented Feb 19, 2016

Update,

v.1.6.2 doesn't have this issue.

@peyoh peyoh changed the title live profile issues with the latest checkout live profile issues with the latest checkout (v.1.6.3) Feb 19, 2016
@peyoh peyoh changed the title live profile issues with the latest checkout (v.1.6.3) live profile issues with the latest release (v.1.6.3) Feb 19, 2016
@joeyparrish
Copy link
Member

@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
Copy link
Author

peyoh commented Feb 22, 2016

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
Copy link
Author

peyoh commented Feb 24, 2016

@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
Copy link
Contributor

tdrews commented Feb 24, 2016

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).

@joeyparrish joeyparrish changed the title live profile issues with the latest release (v.1.6.3) update of live manifest with large timeShiftBufferDepth is slow Feb 25, 2016
@joeyparrish joeyparrish added the type: bug Something isn't working correctly label Feb 25, 2016
@joeyparrish joeyparrish added this to the v2.0.0 milestone Feb 25, 2016
@peyoh
Copy link
Author

peyoh commented Feb 26, 2016

@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 joeyparrish removed this from the v2.0.0 milestone Feb 26, 2016
@joeyparrish joeyparrish assigned joeyparrish and unassigned tdrews Feb 26, 2016
@joeyparrish
Copy link
Member

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

@joeyparrish joeyparrish added this to the v1 maintenance milestone Feb 27, 2016
shaka-bot pushed a commit that referenced this issue Feb 27, 2016
Adding assertion messages when missing was slowing down the code
because of the repeated throwing at catching of exceptions.  Now
only add a stack trace if the assertion will fail.

Issue #288

Change-Id: Ic4ec3180df0178f1e3e0b25534d9e5bb018707a4
@joeyparrish
Copy link
Member

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

@peyoh
Copy link
Author

peyoh commented Mar 1, 2016

Hello,
yes it is fixed. Thank you!

BRS

@joeyparrish
Copy link
Member

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

@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

5 participants