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.

Sign up for GitHub

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

Jump to bottom

Regression in segment time calculation - presentationTimeOffset is added when it should not be #1232

Closed
sandersaares opened this issue Jan 17, 2018 · 20 comments
Closed

Regression in segment time calculation - presentationTimeOffset is added when it should not be #1232

sandersaares opened this issue Jan 17, 2018 · 20 comments
Assignees
@TheModMaker
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone
v2.4

Comments

@sandersaares
Copy link
Contributor

sandersaares commented Jan 17, 2018 •
edited
Loading

2075050 appears to have introduced a regression, with the key line in question being https://github.com/google/shaka-player/blame/master/lib/dash/segment_template.js#L324. Possibly more of the logic is suspect - I did not dig deeper beyond finding why the first numbers with my video were off.

As far as I can tell, the function find appears to be there to determine the MPD start time in seconds segment position of the segment containing periodTime, which is an offset from the start of the period in seconds.

Using presentationTimeOffset in this calculation is incorrect. PTO does not determine anything about the MPD timeline, it says what media timestamp (PTS) corresponds to periodTime = 0. You should only use it for aligning the media timeline with the MPD timeline.

The referenced commit causes any segmentTemplate-using streams with presentationTimeOffset to have segments scheduled at the wrong moments in time.

Still working on getting playable URL for you but I thought I would post immediately as it seemed pretty clear cut to me. Let me know if you want more supporting material and evidence and I am happy to provide.

Example MPD:

<MPD type="dynamic" availabilityStartTime="1970-01-01T00:07:00Z" profiles="urn:mpeg:dash:profile:isoff-live:2011,http://dashif.org/guidelines/dash264" timeShiftBufferDepth="PT15M" minimumUpdatePeriod="PT15S" minBufferTime="PT2S" publishTime="2018-01-17T14:49:04.237755Z" xmlns="urn:mpeg:dash:schema:mpd:2011">
  <!--availabilityStartTime is adjusted to add a delay of 00:07:00 to the availability timeline compared to the authoring timeline. Timestamps in period/segment paths indicate authoring time (UTC), not availability time (UTC+delay). Playback uses availability time.-->
  <Period id="p_1516198946762" start="P17548DT14H22M26.762S">
    <!--Starts 2018-01-17 14:21:59.762Z (1,516,198,946,762 ms from epoch) on the authoring timeline.-->
    <!--Starts 2018-01-17 14:28:59.762Z (1,516,199,366,762 ms from epoch) on the availability timeline.-->
    <AdaptationSet segmentAlignment="true" group="1">
      <SegmentTemplate timescale="1000" duration="4000" media="p_1516198946762/$RepresentationID$/$Number%06d$.m4s" initialization="p_1516198946762/$RepresentationID$/init.mp4" presentationTimeOffset="1516198946762" />
      <Representation id="Track0" mimeType="audio/mp4" startsWithSAP="1" bandwidth="64000" audioSamplingRate="48000" codecs="mp4a.40.2" />
    </AdaptationSet>
    <AdaptationSet segmentAlignment="true" group="2" par="16:9" maxHeight="720" maxWidth="1280" frameRate="30">
      <SegmentTemplate timescale="1000" duration="4000" media="p_1516198946762/$RepresentationID$/$Number%06d$.m4s" initialization="p_1516198946762/$RepresentationID$/init.mp4" presentationTimeOffset="1516198946762" />
      <Representation id="Track1" mimeType="video/mp4" startsWithSAP="1" bandwidth="3000000" sar="1:1" width="1280" height="720" codecs="avc1.640032" />
    </AdaptationSet>
  </Period>
  <UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="Manifest.mpd" />
</MPD>

The period starts at some point on 2018-01-17. Both the MPD timeline zero point and the media timeline zero point are in 1970. The latter is indicated by presentationTimeOffset. The first segment to be played at period start is number 1.

However, because of the problematic commit, Shaka adds PTO to the first segment, trying to play back something from 2066 instead (it tries to play segment number 379054268 as I post this).
@sandersaares
Copy link
Contributor Author

sandersaares commented Jan 18, 2018 •
edited
Loading

Here's an externally accessible URL from a development server: https://live.axtest.net/routes/lapd-v1-cb/www_c1/Manifest.mpd

I expect it will stay up for around 6-7 hours from this comment. After that it might stop publishing the period with presentationTimeOffset due to a known issue. Stream should be relatively stable now.

@TheJohnBowers TheJohnBowers mentioned this issue Jan 19, 2018
Closed
This was referenced Jan 24, 2018
Closed
Closed
@sandersaares
Copy link
Contributor Author

This is breaking a lot of streams. Can we get a fix in the near future @joeyparrish? We're currently not able to upgrade to latest version due to this blocking us.

@stroemlund
Copy link

We have a problem where shaka 2.3.1 want start playing our streams however dashif, bitmovin and older shaka versions starts playing the mpeg dash streams immediately Shaka keeps saying there is an issue with the time of the segments however all other players are playing back our streams just fine. Could these issues be related? I can provide a test url for any of the devs if wanted. Just can't post it public.

@TheModMaker TheModMaker added type: bug Something isn't working correctly and removed needs triage labels Jan 29, 2018
@TheModMaker TheModMaker added this to the v2.4.0 milestone Jan 29, 2018
@TheModMaker TheModMaker self-assigned this Jan 29, 2018
@joeyparrish
Copy link
Member

This should be working now in the nightly build: https://nightly-dot-shaka-player-demo.appspot.com/demo/

Can someone please confirm?

@stroemlund
Copy link

stroemlund commented Feb 1, 2018 via email

@joeyparrish joeyparrish reopened this Feb 1, 2018
@joeyparrish
Copy link
Member

@TheModMaker, can you please take a look?

@sandersaares
Copy link
Contributor Author

I confirm the stream I posted appears to work with the nightly build.

@TheModMaker
Copy link
Contributor

@stroemlund Can you give us a manifest URL?

@stroemlund
Copy link

stroemlund commented Feb 1, 2018 via email

@TheModMaker
Copy link
Contributor

@stroemlund That manifest doesn't use presentationTimeOffset, so the issue is unrelated.

When I fetch the manifest at 2018-02-01T17:50:49Z, the availabilityStartTime is 2018-01-29T07:43:30Z, which puts the live edge at 295639 seconds. The first segment in the manifest is at 26610480000 / 90000 or 295672 seconds, which is in the future. It looks like your stream is suffering from drift. See #999.

Since this is unrelated I'm closing the issue. If you have problems with another stream, you should probably file a new issue.

@stroemlund
Copy link

stroemlund commented Feb 1, 2018 via email

joeyparrish pushed a commit that referenced this issue Feb 1, 2018
@TheModMaker @joeyparrish
Fix SegmentTemplate w/ duration.
152d6e1 
We incorrectly added the presentationTimeOffset to the segment times as
a fix for #1164.  The correct fix is to use the include the PTO in the
time structure passed to the text parsers.  This is a partial revert
of 207505.

Issue #1164
Closes #1232

Change-Id: I1f2805e0dbdc44be71e2160b3d37a73732c97a4f
@joeyparrish
Copy link
Member

Cherry-picked for v2.3.3. The correctness of the fix was still being debated while I was preparing v2.3.2. Sorry for any inconvenience caused by delaying this fix for one more release.

@stroemlund
Copy link

stroemlund commented Feb 2, 2018 via email

@TheModMaker
Copy link
Contributor

TheModMaker commented Feb 2, 2018 •
edited by joeyparrish
Loading

No, we are still working on fixes for drift, which you can follow in #999. The fix for SegmentTemplate with duration will appear in 2.3.3.

@stroemlund
Copy link

stroemlund commented Feb 2, 2018 via email

@joeyparrish
Copy link
Member

Referring to the analysis above in #1232 (comment), if the segment times are in the future, it sounds like it's not drift, but rather a clock sync or encoder clock issue. Is the clock on your encoder correct? Do you have clock sync set up on the content?

@stroemlund
Copy link

stroemlund commented Feb 2, 2018 via email

@joeyparrish
Copy link
Member

I don't know, but it could be a bug in the Elemental encoder. Have you talked to Elemental support?

@stroemlund
Copy link

stroemlund commented Feb 12, 2018 via email

@joeyparrish
Copy link
Member

As far as we can tell (analysis above), the segment times are in the future. Since we are already planning a general approach to ignore availabilityStartTime (#999), I don't think there's anything more specific we can do for you right now. I expect your problem will be solved once #999 is implemented. In the mean time, you are always welcome to customize Shaka Player sources however you need to for your deployment.

Sorry we couldn't do more for you directly. If you subscribe to #999, you will be notified when we close the issue.

@shaka-project shaka-project locked and limited conversation to collaborators Apr 2, 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.
Assignees

@TheModMaker TheModMaker

Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Milestone
v2.4
Development

No branches or pull requests
5 participants
@stroemlund @TheModMaker @joeyparrish @sandersaares @shaka-bot