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

Time synchronization problems #345

Closed
ArhiChief opened this issue Apr 19, 2016 · 6 comments

Comments

Projects
None yet
5 participants
@ArhiChief
Copy link

commented Apr 19, 2016

Hi there.

We are using shaka-player to provide live stream service with MPEG-DASH.
Everything works fine on v2.0.0-beta.

Here is the MPD we use for live service:

<?xml version="1.0"?> <MPD type="dynamic" xmlns="urn:mpeg:dash:schema:mpd:2011" availabilityStartTime="2016-04-19T18:33:36+00:00" availabilityEndTime="2016-04-19T19:25:47+00:00" minimumUpdatePeriod="PT5S" minBufferTime="PT5S" timeShiftBufferDepth="P0Y00M00DT0H01M11.05S" suggestedPresentationDelay="PT10S" profiles="urn:hbbtv:dash:profile:isoff-live:2012,urn:mpeg:dash:profile:isoff-live:2011" xmlns:xsi="http://www.w3.org/2011/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd"> <Period start="PT0S" id="dash"> <AdaptationSet id="1" segmentAlignment="true" maxWidth="640" maxHeight="480" maxFrameRate="0"> <Representation id="bsp1_H264" mimeType="video/mp4" codecs="avc1.42001e" width="640" height="480" frameRate="0" sar="1:1" startWithSAP="1" bandwidth="0"> <SegmentTemplate presentationTimeOffset="0" timescale="1000" media="bsp1-$Time$.m4v" initialization="bsp1-init.m4v"> <SegmentTimeline> <S t="3060933" d="11927"/> <S t="3072860" d="11914"/> <S t="3084774" d="11798"/> <S t="3096572" d="11754"/> <S t="3108326" d="11711"/> <S t="3120037" d="11950"/> </SegmentTimeline> </SegmentTemplate> </Representation> </AdaptationSet> </Period> </MPD>

Everything work well on the systems with correct system clock time.
But, when the system clock time changes (for example in +/- 1-2 minutes) the shaka-player throws an 5002 error:

video:1)next segment does not exist:lookupTime=3446.071000099182time=3446.071000099182currentPeriod.startTime=0mediaState.drift=null Player errorshaka.util.Error { "category": 5, "code": 5002, "data": [ "video", 0, 3446.071000099182 ], "message": "Shaka Error STREAMING.SEGMENT_DOES_NOT_EXIST (video,0,3446.071000099182)", "stack": "Error: Shaka Error STREAMING.SEGMENT_DOES_NOT_EXIST (video,0,3446.071000099182)\n at new shaka.util.Error (http://shaka-player-demo.appspot.com/lib/util/error.js:77:13)\n at shaka.media.StreamingEngine.lookupSegmentPosition_ (http://shaka-player-demo.appspot.com/lib/media/streaming_engine.js:1035:11)\n at shaka.media.StreamingEngine.getSegmentReference_ (http://shaka-player-demo.appspot.com/lib/media/streaming_engine.js:964:21)\n at shaka.media.StreamingEngine.update_ (http://shaka-player-demo.appspot.com/lib/media/streaming_engine.js:858:24)\n at shaka.media.StreamingEngine.onUpdate_ (http://shaka-player-demo.appspot.com/lib/media/streaming_engine.js:728:22)" } Updating manifest... Updating manifest...

Same error didn't occurs in dash.js v.2.1.0 beta. Looks like, dash.js use synchronization with time servers.

For more test, I can provide a link to MPD: http://40.68.161.223/dash/bsp1.mpd

Thanks in advance.

@tdrews tdrews added the enhancement label Apr 19, 2016

@tdrews tdrews added this to the v2+ milestone Apr 19, 2016

@tdrews

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2016

Hi,

Shaka v2 does use the UTCTiming element for clock synchronization; however, it only does so after it fetches the MPD for the first time. I'll mark this as an enhancement for now, and we'll discuss internally what our options are for clock synchronization throughout playback.

@ArhiChief

This comment has been minimized.

Copy link
Author

commented Apr 20, 2016

Hi.
Thanks for response.

As I understand, you synchronize time only for first MPD, and part of segments from MPD must be loaded and played, but if we have incorrect time while loading page with player, shaka throws error just after first mpd loaded.

@tdrews tdrews added the bug label Apr 20, 2016

@tdrews

This comment has been minimized.

Copy link
Contributor

commented Apr 20, 2016

... but if we have incorrect time while loading page with player, shaka throws error just after first mpd loaded.

We should be correcting the time after the first MPD is loaded, so it sounds like there might be another issue here. We'll investigate.

@tdrews tdrews modified the milestones: v2.0.0, v2+ Apr 20, 2016

shaka-bot pushed a commit that referenced this issue Apr 22, 2016

Update clock sync on manifest update.
Issue #345

Change-Id: I9faef800444e3b818c8da64cf71848a99713c3ff
@TheModMaker

This comment has been minimized.

Copy link
Member

commented Apr 22, 2016

Now the clock will synchronize on manifest updates, so if the clock changes it will be updated on the next manifest update. Please test again on master.

Also, the manifest in your description does not contain a UTCTiming element. Without it, Shaka will not do clock sync at all. See this example from Dash IF:

http://vm2.dashif.org/livesim/utc_direct-head/testpic_2s/Manifest.mpd

@tdrews tdrews removed the bug label Apr 22, 2016

@tdrews tdrews modified the milestones: v2+, v2.0.0 Apr 22, 2016

@ArhiChief

This comment has been minimized.

Copy link
Author

commented Apr 22, 2016

Oh, thanks. We will update our software, make some test and tell you results.

@ArhiChief

This comment has been minimized.

Copy link
Author

commented Apr 25, 2016

Looks like it works. I'd add inside MPD element of my manifests. Thank you.

shaka-bot pushed a commit that referenced this issue May 4, 2016

Revert "Update clock sync on manifest update"
Hitting UTCTiming sources over and over could be considered abusive
behavior at scale, so we will only sync the clock once on startup.

The change to update clock sync on manifest update was added for #345,
but it seems that this was not part of the fix, since the content in
that issue had no UTCTiming element at all.

Change-Id: I32f4fc0a40fc92feeb54191e5fe869e0aaa9b54c

@joeyparrish joeyparrish removed this from the v2+ milestone May 20, 2016

@shaka-bot shaka-bot added the archived label Mar 22, 2018

@google google locked and limited conversation to collaborators Mar 22, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.