You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a request to discuss use of in-band lmsg signalling, as defined in 4.4.3.5. of IOP V4.3. Perhaps I've misunderstood its usage, but from an initial read:
The on-demand case seems very hacky. Why wouldn't an on-demand manifest be able to tell a client directly at the manifest level when a period ends? Also, if a manifest doesn't do this that would tend to imply that there must exist a gap in media at the end of the content, which probably violates the new DASH timing model proposed by @sandersaares (please correct me if I'm wrong).
For the live case, what functionality does it provide that cannot already be done with urn:mpeg:dash:event:2012InbandEventStream triggering a manifest refresh, which could then indicate accurately what the last segment is.
The text was updated successfully, but these errors were encountered:
I concur with the skeptical outlook and do not see a meaningful use case for this feature.
We briefly touched upon it at the December 2018 F2F and all the discussed use cases involved packagers unable to correctly indicate timing in the MPD, for one reason or another, which is not a situation I would want to encourage or declare interoperable.
One scenario worth specific mention was the case where you use simple addressing, which allows for the start/end inaccuracy. If we apply this rule to all segments equally, the last segment N might very short (simply due to period length), which would enable the penultimate segment N-1 to already contain all samples of segment N within its legal inaccuracy range. Therefore, addressing-wise there would exist a segment but sample-wise it would have zero samples and possibly be not generated or considered invalid (depending on interpretation). Thus there was talk of embedding a lmsg into the penultimate segment to say "this is it".
This scenario is not legal by my proposed interoperable timing model - the MPD must be accurate (always) and the samples at the start/end points must be within the correct segments (even if otherwise within legal range of other segments). Yes, this does constrain period-cutting abilities of the packager using simple addressing. These limitations could be somewhat lessened if https://github.com/Dash-Industry-Forum/DASH-IF-IOP/issues/245 is fixed by MPEG (I recall there was a proposal to do this; I do not know what came of it). Alternatively, explicit addressing could be used.
This is a request to discuss use of in-band lmsg signalling, as defined in 4.4.3.5. of IOP V4.3. Perhaps I've misunderstood its usage, but from an initial read:
urn:mpeg:dash:event:2012
InbandEventStream
triggering a manifest refresh, which could then indicate accurately what the last segment is.The text was updated successfully, but these errors were encountered: