-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
presentationTimeOffset added twice for segment-relative cue times #595
Comments
I recognize that this is what the spec says, and we should honor it, but it is a huge pain! It means that the packager needs to be aware of ad breaks, blackouts, and key rotation so that it can set period relative timestamps on text tracks. This feels like unnecessary complexity! Does anybody else agree that this is an undue burden? I will create an issue with the IOP... |
From IOP viewpoint, text should be in ISOBMFF in order to achieve interoperable playback. This also eliminates the need to care about period timeline. Quoting IOP section 6.4.2:
|
@sandersaares, so then the IOP really shouldn't have a stance on what the timeline of sidecar files should be, right? This runs contradictory to @sanbornhnewyyz's quote above. |
Well, that gets somewhat into philosophical areas. Should DASH-IF care about interoperability even when people use obsolete/nonrecommended mechanisms? If yes, implementations will be more unified but it might also lend some unwanted credibility to the approach in question. If no, it is likely that implementations will diverge and people will be unhappy with DASH as a technology. Both approaches have upsides and downsides. The former has been selected as the favored one in this instance. I think, on balance, it is the better of the two. |
Sure, I'm all for providing guidance on divergent implementations. With that said, I maintain that it creates undue burden on the packager to require that plaintext sidecar files provide period-relative timestamps. @sandersaares do you think the IF would consider revising this requirement? |
I consider it unlikely but you can certainly file an issue on the IOP tracker and try to convince people to change it: https://github.com/Dash-Industry-Forum/DASH-IF-IOP/issues |
Okay, sorry for joining the conversation so late. @sanbornhnewyyz, in your example, there's one critical thing missing from my point of view: <SegmentTemplate timescale="10000000" presentationTimeOffset="1796832000000000" media="$RepresentationID$/Segment-$Time$.vtt">
<SegmentTimeline>
<S t="1796832000000000" d="20000000" r="1049" />
</SegmentTimeline>
</SegmentTemplate> What does this VTT file look like at t="1796832000000000"? If the manifest is correct, the timestamps in that VTT file should look something like this:
Is that the case in your example? If not, I think the content is broken, not the player. The point of the manifest is to describe the content. A web app should not have to parse an MP4 file to know the timestamp of a segment. It should know from the manifest what the start time and duration of a segment are. To summarize what's already been said, media segments are on a different timeline from the presentation itself. So presentationTimeOffset allows the manifest to describe to the player how they should be aligned. For example, SegmentTimeline would use t=X if the segment's own PTS was X. If that segment needed to appear at time Y in the period, presentationTimeOffset would be Y-X. In this way, the manifest both describes what is in the media segment and what the player should do with it. In MediaSource, we set So, image you have a VTT file that says this:
And a manifest that describes the segment like this: <SegmentTemplate timescale="1" media="$RepresentationID$/Segment-$Time$.vtt">
<SegmentTimeline>
<S t="123456" d="10" /> Then the manifest does not accurately describe the content. I'm not using presentationTimeOffset in this example because it doesn't matter. The media segment (VTT file) has internal timestamps just like an MP4 would, but the manifest describes that segment as having a completely different timestamp. The manifest should always describe the media accurately. If the VTT file and manifest don't agree, one or the other needs to be adjusted. Again, this has nothing to do with presentationTimeOffset. The SegmentTimeline needs to reflect the contents of that segment - always. |
@joeyparrish I see what you are saying but the segmented VTT files we are receiving have segment relative timestamps. So the example you provide:
Would actually look like this:
Hence applying any offset will cause a problem IF the assumption is that text tracks always align with the beginning of the period. I question this:
Because this seems to suggest otherwise:
At the end of the day, I don't disagree that there is a problem with the manifest we are receiving. Our proposal to fix this problem was to have the text track offset removed from the manifest. But depending on how that DASH-IF IOP is interpreted it would seem that ignoring presentation time offsets for plaintext tracks might be the way to go. |
Okay, I see the problem now. We have the media timeline, the presentation time offset, the timestamps in the segment reference object, the period start, and the presentation timeline. Say the timestamp in a media segment is 10, as parsed from the SIDX or the manifest. We then apply the presentation time offset to that and store it in the segment reference object. The segment reference time is relative to the period start. Then, to get to the presentation timeline, we add the period start to the segment reference time. The timestamps passed to Unconditionally, we add the offset to the cue times. Then, if useRelativeCueTimestamps is set, we add the segment timestamp to the cue times. So if useRelativeCueTimestamps is set, we have accounted for the offset twice! The solution is to either add the offset (for period-relative timestamps) or the segment time (for segment-relative timestamps), but never both. Make sense? |
I'm copying a conversation here from #480 because I believe it requires its own issue.
We have content that contains the following:
what would be the expected result? Video and audio times are calculated correctly but text cues are all generated starting at -1796832000000000. I'm looking at the DASH spec but I'm still unsure how the startTimes are supposed to be calculated.
@sandersaares commented:
@sandersaares Thank you for pointing me in the right direction, I had not read that.
In that section (DASH-IF IOP 6.4.5) it says:
According to this it looks like Shaka should be ignoring the presentationTimeOffset if its present. And if I am reading it correctly this is actually independent of the issue of relative timestamps.
I think Shaka should be ignoring the presentationTimeOffset in the manifest above.
The text was updated successfully, but these errors were encountered: