-
Notifications
You must be signed in to change notification settings - Fork 0
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
New Proposal: Patterns in Segment Timeline #75
Comments
AHG 2023/03/03 Different options discussed:
Other options? Please comment |
From my own notes of the discussion, with listing of some pros/cons
I think at a high level, if a content producer is using explicit addressing mode, there are performance advantages to providing a mechanism for reducing the manifest size (primarily on the initial request, as patch syntax allows for reduced update sizes). |
AHG Call 2023/03/24 Proposal
|
I'll write up a revised proposal for a more backwards-compatible Of note, I was reviewing documentation and implementations. In particular, one case for having an explicit addressing mode (ie an explicit timeline) is when an Ad Insertion MPD Manipulator proxies directly from an IF-2 or IF-3 input. In particular, there exist cases where ad insertion cannot fill an ad break, and must return to main content, or otherwise adjust the Period@start and prescribed segments in a Period. With simple addressing mode, adjusting Period@start is limited by the DASH-IF timing constraints: https://dashif-documents.azurewebsites.net/Guidelines-TimingModel/master/Guidelines-TimingModel.html#addressing-simple-startpoint In particular:
As such, in an ad-insertion architecture, simple-addressing mode either:
With a |
I was also thinking about dynamic ad-insertion scenario for which I thought it will be very tricky to manage the matching between the segment numbers and the PatternTimeline. Also, consider the case you currently deliver manifests with SegmentTimeline, primarily to get around issues introduced by simple-addressing mode, especially the ones Kyle listed in previous comment. In short, you would resolve the manifest size issue for up to date players compatible with the PatternTimeline, while introducing some other issues for legacy players who will have to use the numbers. Accordingly, if one wants to reduce size of manifests using SegmentTimeline, there may be no alternative way than introducing this new Pattern syntax under the existing SegmentTimeline and breaking the backward compatibility with legacy players. |
Notes from meeting today: Potential options:
In conjunction:
, whereby "loosen" would be restricted to being off by a particular threshold (I'm not sure by how much, however). For a DASH client which relies on time-accuracy, the |
@bbert Is your assertion that using a |
@koceskik yes my understanding of @haudiobe's initial proposal is that if you want to signal a Now thinking back on last proposal, with this example:
and for which the segment starting for example at timestamp Finally the result is the same except that, compared to previous solution, you can signal for example gaps in both timelines since you are not forced to address segments using However that solution still requires some tricky processing for clients that read and interpret that new pattern timeline since you need to keep matching between the segments from both timelines, especially for content replacement. That will be source of errors and interoperability issues. Questions:
|
AHG 2023/04/14 @agiladi suggests to also indicate the tolerance - a concrete proposal would be welcome. |
@agiladi mentioned milliseconds, but the most natural tolerance would be to use the same units as the rest of the timestamps. Maybe his suggestion would be different, but I think the following example would make sense: For 48kHz audio with timescale 48000, an AAC frame's duration is 1024 ticks. It is therefore possible to always achieve a duration of an audio segment that is within 1024 ticks from the average. A bigger variation would require a new
rather than
|
[edited for @tobbee 's comment above]
we can explicitly specify tolerance
The semantics will be that for any segment the actual value in Assuming audio frame duration of 1024, this lets us do a pattern where we add an extra audio frame to every Nth segment to maintain a/v segment alignment. |
Completely agree with the above, it should be in units of the same timescale as used in |
It should not be tfdt, but presentation time. |
I'm of the opinion that adding At which point, why not go with the original proposal of adding a In general, I think it could make sense to include However, if explicit addressing mode is necessary, either because the DASH client can't handle the variability in fragment timings correctly, or the manifest manipulator (ex: for ads insertion) needs accurate timings for handling period bounds manipulation, you're going to need to update your DASH client/manifest manipulator anyways. So, I'm unconvinced that the backwards-compatibility argument is a major point in making a decision, because service offerings that will rely on explicit addressing mode will need to update anyways. At that point, does it make sense to add complexity of a new tag ( (it doesn't sound too complex in that simplified paragraph, but I think there's a few other cases to author explicit clarity on) |
Live TF 2023/05/05
|
@koceskik @bbert @ZmGorynych @technogeek00 any updates on the google docs that we can check tomorrow? |
I've created a doc here: https://docs.google.com/document/d/1O4diz48Lr3LJozloy2MdLO79_Ylj6yjg5f-Jhi0UjPQ |
f2f June
Decision:
|
Did a first pass read of the document, very nicely done @koceskik clearly articulated. I'll think on some descriptive aspects, should we provide comments directly back in the doc? |
Yes, please comment directly in the doc. Until next week, in order to complete submission to MPEG. |
Kyle from AWS presented this now in the IOP WG call.
New topics
• Kyle presents: IOP23011.PatternTemplateManifest_DASH-IF_Reintroduction_2023.pptx
o We will add this to the DASH-IF Live TF on Friday, March 3, 2023
We will discuss this in more details in the Live TF on Friday.
The text was updated successfully, but these errors were encountered: