Closed codeindream closed 6 years ago
email sent
my understanding of "availabilityStartTime" is the time since Epoch time. Should it be something like "availabilityStartTime="1970-01-01T00:00:09Z" ? in that case, it will give a 9 seconds latency from current live point.
Should it be something like "availabilityStartTime="1970-01-01T00:00:09Z" ?
My understanding, it's time when stream started.
For example, in DashMediaSource#processManifest(): long liveStreamDurationUs = getNowUnixTimeUs() - C.msToUs(manifest.availabilityStartTimeMs);
Regarding issue _#1, I think Exoplayer expecting that livestream couldn't be played with suggestedPresentationDelay = 0
, as it mean that we at livestream edge, so chunks phisicaly can't be ready.
But in that case, why it starting to play after 5 sec and continue?!
In DashMediaSource
I found logic: handler.postDelayed(simulateManifestRefreshRunnable, NOTIFY_MANIFEST_INTERVAL_MS);
where NOTIFY_MANIFEST_INTERVAL_MS = 5000
.
This is the reason of issue _#2. But why there's difference for first and next iterations?
Ok, so I found some answers on my questions:
- After first chunk received, player show seek bar for 5M with position at the end. Content not playing, only init and first chunk downloaded.
When Exo get live stream, initial playback duration calculated as suggestedPresentationDelay + timeShiftBufferDepth
with start position at playback end - suggestedPresentationDelay
.
So, when we load manifest from question, playback duration = 5m with start at the end -> nothing to play.
- than each ~5 sec seek position moved back to ~4:52 and content start/continue playing
Exo has internal manifest reload, as I understand, to reload current playback position. As previous position was at the end of stream, and 5 sec pass, we start to play from 4:55~4:52.
- if buffering state occur during playback, player waiting for new chunks and continue to play from last place. But we expecting to keep ~8sec latency from realtime, by skipping frames, if required.
This is fixed default behavior. Looks like for another behavior we need to customize Exo.
- As latency very low, 404 is often and expected state for chunk requests. But segments get to blacklist and after some time, lowest quality selected.
Blacklisting can't be disabled. Could be achieved by overloading DefaultDashChunkSource.onChunkLoadError()
and check if ChunkedTrackBlacklistUtil.shouldBlacklist(e) = true
return false.
Issue description
Hello!
We'd like to use Exoplayer for DASH+DRM live streaming with latency ~8 sec and timeShiftBuffer = 5M. Priority is to keep stream latency ~8 sec from realtime (skip frames if required).
Our manifest working well for Shaka player, but with Exo we observs next issues:
Reproduction steps
DASH manifest example:
Version of ExoPlayer being used
Exoplayer v2.6.1
Device(s) and version(s) of Android being used
Samsung: s5 (5.0), Note 5 (7.0) Emulator x86 (7.1.1) Xiaome Redmi 4 (7.0)