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

Support for MPD Anchors #1361

Closed
LloydW93 opened this issue Apr 27, 2016 · 13 comments · Fixed by #1390
Closed

Support for MPD Anchors #1361

LloydW93 opened this issue Apr 27, 2016 · 13 comments · Fixed by #1390
Labels
Feature Enhancement stale To be used by automatic issue staling and closing to indicate that this issue is about to be closed
Milestone

Comments

@LloydW93
Copy link
Member

Dash.js already has support for "#s=n", where n is a start offset in seconds. However, ISO23009-1 Appendix C specifies four MPD anchors:

Key Value Semantics
t Time or time range in the same format as defined in Media Fragments URI 1.0 Time since the beginning of the period indicated by the period parameter. If the t parameter is not present, its default value is 0.
period String Period@id. If period parameter is not present, the default value is the ID of the Period with the earliest PeriodStart.
as string Value of a single AdaptationSet@id
track string Value of a single AdaptationSet@group

Dash.js should add support for at least #t, as this is something that current works if you pass an media url to a native media tag in a browser (https://www.w3.org/TR/media-frags/).

@LloydW93 LloydW93 added this to the 2.2.0 milestone Apr 27, 2016
@davemevans
Copy link
Contributor

Note that the examples in Appendix C are incorrect and were fixed in Corrigendum 1.

@LloydW93
Copy link
Member Author

LloydW93 commented May 9, 2016

#1390 handles #t, which is the one we're interested in our use case. Does anyone have a desire to use the others? If not I think they may be best left on the backlog until someone wants them.

@davemevans
Copy link
Contributor

davemevans commented May 23, 2016

As discussed at the F2F, #1390 only supports value specified in seconds for t. That's probably OK, but worth noting somewhere that it does not fully support Time or time range in the same format as defined in Media Fragments URI 1.0.

@wilaw
Copy link
Member

wilaw commented May 24, 2016

Media Fragments URI 1.0 is a set of broad requirements, including spatial descriptors, many of which are edge case requirements. In support of @LloydW93's proposal, I would think we can cherry pick a subset of this to support at first for dash.js, specifically:

t=10,20 # => results in the time interval [10,20)
t=,20 # => results in the time interval [0,20)
t=10 # => results in the time interval [10,end)

Additionally, I think supporting the utc parameter as defined by Amd.3 of ISO/IEC 23009-1:2014 would be most useful in practice:

Start a live stream at Wed, 21 Jan 2015 20:04:05 GMT
   my.mpd#utc=1421870645
A live stream range from Wed, 21 Jan 2015 20:04:05 GMT to Wed, 21 Jan 2015 23:44:33 GMT
   my.mpd#utc=1421870645,1421883873
If mpd@type=dynamic, play the stream from the latest available segment to Wed, 21 Jan 2015 23:44:33 GMT
   my.mpd#utc=now,1421883873
If mpd@type=static, play the stream from the earliest available segment to Wed, 21 Jan 2015 23:44:33 GMT
   my.mpd#utc=,1421883873

We can add support for other features of MediaFragments and Amd 3:2014 if and when people come forth and say they need them.

@LloydW93
Copy link
Member Author

The case of stopping at specific times isn't yet implemented. This should be relatively simple:

  • A check in timeupdate to stop playback (and fake an ended event at that time)
  • A check in the scheduled to consider the stream complete if the requested fragment starts beyond the requested range end time
  • BOLA's consideration of buffer in this case?

However, what UX should be exposed in this case, at least in the reference player? Is the entire available period exposed in the seek bar (and in the DVR Info by dash.js for live streams), or only the requested range? I'm thinking dash.js should always expose the entirely available range and leave that decision to the client, but that then means we need to ensure that seeking out of the initially provided range is handled.

@LloydW93 LloydW93 reopened this Jun 1, 2016
@dsparacio dsparacio modified the milestones: v2.3.0, 2.2.0 Jul 5, 2016
@bwidtmann
Copy link
Contributor

bwidtmann commented Aug 22, 2016

the changes are currently not part of development branch. is this intented?

@LloydW93
Copy link
Member Author

We currently only support #t= and #s=, and then only without ranges. We do generally have a desire to implement these further though, as it will be incredibly useful for MPD chaining.

@bwidtmann
Copy link
Contributor

@LloydW93 I only see support of #s in development branch in PlaybackController.js in getStreamStartTime

@dsparacio
Copy link
Contributor

So looks like it was reverted by dave and I do not see the changes in the PR in dev either so must of not been included after the revert. @LloydW93 I faintly remember a discussion around this but do not have a clear idea if we made a mistake and did not re-add the code lines.

@bwidtmann
Copy link
Contributor

as @LloydW93 already mentioned: at least the support of #t should be implemented, which should be a 1 liner.

dsparacio pushed a commit that referenced this issue Aug 29, 2016
Fix regression resulting in #t no longer working (see issue #1361)
@dsparacio dsparacio modified the milestones: v2.4.0, v2.3.0 Sep 6, 2016
@dsparacio dsparacio modified the milestones: v2.5.0, v2.4.0 Jan 4, 2017
@fvalleeHbbTV
Copy link

FYI I'm interested in #period support !

@stale
Copy link

stale bot commented Feb 26, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale To be used by automatic issue staling and closing to indicate that this issue is about to be closed label Feb 26, 2021
@stale
Copy link

stale bot commented Mar 5, 2021

This issue has been automatically closed because no further activity occurred. If you think this issue is still relevant please reopen it. Thank you for your contributions.

@stale stale bot closed this as completed Mar 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Enhancement stale To be used by automatic issue staling and closing to indicate that this issue is about to be closed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants