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.

Sign up for GitHub

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

Jump to bottom

Support live streams #21

Closed
joeyparrish opened this issue Feb 12, 2015 · 9 comments
Closed

Support live streams #21

joeyparrish opened this issue Feb 12, 2015 · 9 comments
Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request
Milestone
v1.3.0

Comments

@joeyparrish
Copy link
Member

Shaka Player should support DASH live content.
@joeyparrish joeyparrish added the type: enhancement New feature or request label Feb 12, 2015
@joeyparrish joeyparrish changed the title Live stream support Support live streams Feb 13, 2015
@joeyparrish joeyparrish added this to the v1.3 milestone Feb 13, 2015
@TobbeMobiTV
Copy link

The livesimulator developed for DASH-IF, http://vm2.dashif.org/livesim/testpic_2s/Manifest.mpd plays in dash.js and in the dev branch of ExoPlayer. Would be nice if you could make it play in shaka-player as well. More info available at http://vm2.dashif.org/

@joeyparrish
Copy link
Member Author

Hi Torbjörn,

Thanks for the link! We will be sure to make that part of our testing as we work on this feature.

tdrews pushed a commit that referenced this issue Mar 20, 2015
Implement initial support for live streams.
44af1e4 
* Implement an update() method on StreamVideoSource that merges
  a new manifest into its existing one.
* Re-fetch and re-process MPDs from DashVideoSource to generate new
  SegmentReferences.
* Compute last available segment numbers and times in MpdProcessor
  when generating SegmentLists.
* Re-work Period computation in MpdProcessor.
* Handle stream EOF differently for live content.

Additional work is required to handle all "styles" of manifests.

Issue #21

Change-Id: I38be9513dc73e4683d1079b4dedb489e8206043d
joeyparrish added a commit that referenced this issue Mar 20, 2015
@joeyparrish
Best-effort clock synchronization.
d481fdc 
The clock will be synced, when possible, to the server hosting the
MPD.  The synced clock will only be used in places where accurate
time matters, such as in loggable player stats and in live streaming.

Relates to #21

Change-Id: Id9da1cf23a781f2ce07a46e0936695d512a65133
tdrews pushed a commit that referenced this issue Mar 27, 2015
Write tests and fix bugs with manifest updates.
069d8c3 
* Write an initial set of unit tests for
  StreamVideoSource.update().
* Correctly handle new manifests that omit periods, stream sets,
  and streams that existed in the original manifest.
* Make StreamVideoSource.update() synchronous.
* Disallow merging SIDX based SegmentIndexes.

Issue #21

Change-Id: Id2e0b8cf56dd4b878b654732b7a088422163f418
tdrews pushed a commit that referenced this issue Mar 27, 2015
Start live streams near the "live-edge".
a8e567c 
* Construct the initial SegmentIndex for a live stream such that it
  includes at least @timeShiftBufferDepth seconds of content before
  the "live-edge".
* Use segment numbers relative to @startNumber instead of relative
  to the start of the Period in SegmentReference to handle MPDs
  with partial segment information.
* Start live streams near the "live-edge", a.k.a., "best start time",
  and start static streams at the latest start time.

Issue #21

Change-Id: I3c553a1b7120a59c68f19cdc85f412f31972c1b8
tdrews pushed a commit that referenced this issue Mar 27, 2015
Update the manifest only when needed.
3e9847a 
For live streams, update the manifest at least every
@minimumUpdatePeriod seconds, but always before the stream exhausts the
list of SegmentReferences.

Issue #21

Change-Id: I71cd75d86ffd342f812621d7d60f4ede4851db83
joeyparrish added a commit that referenced this issue Apr 1, 2015
@joeyparrish
Disallow storing live streams offline.
ade8cbe 
Issues #21 and #22 collide!

Change-Id: I527e7778ba00569f78fd96b2f759688b43753ff5
tdrews pushed a commit that referenced this issue Apr 1, 2015
Recover from unavailable live streams.
5b659ac 
* After updating a manifest restart any streams that failed
  to initially start.
* Seek to the stream start time only after the streams have been
  initialized, seeking before can cause lock-ups with MSE.
* Rename 'bestStartTime' to 'currentSegmentStartTime'.

Issue #21

Change-Id: Ibad91fe2d5171196e93f20961008cdd25ecc437e
joeyparrish added a commit that referenced this issue Apr 1, 2015
@joeyparrish
Ignore 404 and 410 errors on segment fetch.
deb2100 
Relates to #21

Change-Id: Ib834e217aa14b83d2d5e42d05dd65491cab82cb8
tdrews pushed a commit that referenced this issue Apr 4, 2015
Compute seek ranges; refactor Stream creation/startup.
eb78046 
* Compute a seek range in DashVideoSource and update the
  seek range for live streams.
* Fire an event when the seek range changes.
* Refactor stream creation and startup in
  StreamVideoSource: streams are only created and started once all
  streams are available.
* Correct 5b659ac, which set the video's
  current time after the streams have been started. The video's
  current time should be set before the streams start so that the
  correct segment ranges are buffered. Fix buffering issue by
  ensuring the streams do not have disjoint timelines before
  starting.

Issue #21

Change-Id: Ib8f4924b09bfdf0e3b61e25273e16fd313feaf24
joeyparrish added a commit that referenced this issue Apr 4, 2015
@joeyparrish
Add live seek range support to the test UI.
f0f9372 
Issue #21.

Change-Id: Ibc338b46e423d8f7ecafdaa7c2397032faabbd1a
joeyparrish added a commit that referenced this issue Apr 6, 2015
@joeyparrish
Measure MPD fetch latency.
489abbf 
Issue #21.

Change-Id: Id1720fbfb716df414262604d8c1b86c78dd6fe93
tdrews pushed a commit that referenced this issue Apr 6, 2015
Evict unavailable SegmentReferences.
79b638f 
Issue #21

Change-Id: I137f5e1e38f093e355ace5aaa29780bd93980fad
joeyparrish added a commit that referenced this issue Apr 9, 2015
@joeyparrish
Use BUFFER_SIZE_SECONDS_ for sanity only.
23db99c 
The BUFFER_SIZE_SECONDS_ parameter should be used only as a sanity
check in case the MPD specifies a tiny minBufferTime or none at all.
Having a large value meant that we sometimes tried to overbuffer for
live streams.

Relates to issue #21.

Change-Id: If086ef54618621fa77b169be58f4bfc9e255525e
tdrews pushed a commit that referenced this issue Apr 9, 2015
Fix earliest/best segment for SegmentTimeline.
a19ec93 
* Only fallback to 0 for the earliest timestamp if there are
  no segments.
* Don't allow the best timestamp to be less than the earliest
  timestamp.

Issue #21

Change-Id: Ie4df6e36d60adc0ee0dfc54dcbefef7ae0de2705
tdrews pushed a commit that referenced this issue Apr 9, 2015
Only set a target update time for live manifests.
176aac3 
Issue #21

Change-Id: I7bb43972b08f1121268ae5590bd5f456f97659ab
joeyparrish added a commit that referenced this issue Apr 9, 2015
@joeyparrish
Use start time as reference ID.
51563c1 
Since SegmentTimeline streams may not have segment numbers, we should
not use segment numbers as reference IDs.  These IDs must be unique
for the buffering and streaming systems to function properly.

This also adds assertions to check that reference IDs are unique.

Issue #21.

Change-Id: Ia94a48c68149283f87d27c6595a4f5a6cca07a27
joeyparrish added a commit that referenced this issue Apr 16, 2015
@joeyparrish
Refactor 404 handling for live streams.
d3a5daf 
* Remove the acceptableErrors system and replace with a status check
  in SBM on request failure.
* End an SBM fetch task early on 404 or 410, but only during start
  and switch.
* Retry segment fetch to recover from 404/410 errors sooner.
* Set retry delay based on segment duration.
* Remove the 'truncated' fetch mechanism and the 'pleasebuffer'
  mechanism.  (Retry is more robust than entering a buffering state.)
* Retry MPD requests as well.  (Some live streams seem to experience
  very transient 404 errors when requesting updates.)

Issue #21.

Change-Id: I2d3b838a9afe950e9ed0a91da9b952d8a30bf0a1
joeyparrish added a commit that referenced this issue Apr 16, 2015
@joeyparrish
Add docs for live streaming events.
3d6bce9 
Issue #21.

Change-Id: Id45875f7b2630320c2bbeba98a97ff5e8ecfb3dd
@sanbornhilland
Copy link
Contributor

Can I just get clarification on 404 errors? If I use the stream @TobbeMobiTV provided then I get a ton of 404s but the stream appears to be playing back fine. I noticed in deb2100
that you're ignoring these. Does that mean these 404s are acceptable and we can safely ignore them as long we we're getting playback?

@joeyparrish
Copy link
Member Author

Yes, 404s are not ideal, but tolerable. In the case of a live stream, a particular segment yielding 404 means the server has not made it available yet. This could be a result of bad clock sync, or it could mean that we are trying to buffer ahead of the live edge. This should not be fatal to playback.

Depending on suggestedPresentationDelay, minBufferTime, and the particular style of manifest, we may or may not see 404s in v1.3.0. Our Stream and SegmentIndex classes were designed before we supported live content, so we sometimes request segments which are not yet available.

We plan to refactor streaming and indices in 1.4.0 to fix this, after which only clock sync issues and broken manifests should be able to cause a 404. Even then, we will still tolerate 404s and issue clock sync warnings rather than abort playback.

@sanbornhilland
Copy link
Contributor

Great, thanks a lot of the explanation.

@sanbornhilland
Copy link
Contributor

Has shaka been tested with live encrypted content? I've hit a snag trying to play live encrypted content. I can't see where the problem is so I was wondering if you've done this before. This might help me to narrow down the source of the problem.

@joeyparrish
Copy link
Member Author

Yes, it has, both with static keys and with key rotation. From an EME point of view, live content is nothing special.

@sanbornhilland
Copy link
Contributor

Okay, that's what I figured but I wanted to check because I can't figure out why it's breaking down for me. Thanks.

@TobbeMobiTV
Copy link

I'd just like to add that my live simulator is meant as a reference test stream and is very strict on the timing. The segments are only made available during the exact interval which is defined by the DASH standard depending on the availabilityStartTime, startNumber, segmentDuration, and timeShiftBufferDepth. If the request is too early or too late, the simulator actually sends back the amount of time mismatch in the body of the 404 response.

To avoid 404's due to bad timing, the first thing is to make sure about is that the server and client clocks are synchronized. This can be done using the new DASH UTCTiming mechanism. The simulator supports this direct and head mode in its development version at http://vm2.dashif.org/livesim-dev/utc_direct-head/testpic_2s/Manifest.mpd.

@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request
Projects
None yet
Milestone
v1.3.0
Development

No branches or pull requests
6 participants
@TheModMaker @TobbeMobiTV @joeyparrish @sanbornhilland @tdrews @shaka-bot