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

Discussion: lmsg (in-band last segment message) #345

Open
ojw28 opened this issue Jul 10, 2019 · 1 comment
Open

Discussion: lmsg (in-band last segment message) #345

ojw28 opened this issue Jul 10, 2019 · 1 comment

Comments

@ojw28
Copy link

ojw28 commented Jul 10, 2019

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:

  1. 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).
  2. For the live case, what functionality does it provide that cannot already be done with urn:mpeg:dash:event:2012 InbandEventStream triggering a manifest refresh, which could then indicate accurately what the last segment is.
@sandersaares
Copy link
Member

sandersaares commented Jul 11, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants