When switching format in HLS, we instantiate a new extractor, which
adjusts TS presentation timestamps so that they align properly with
the start of the first segment in the new format. Some HLS streams
appear to have slightly misalignment that causes a glitch when using
this approach.
It's better to re-use the same timestamp adjustment across formats,
and only reset it when seeking or when there's an actual discontinuity.
This is because the HLS spec guarantees PTS timestamp alignment across
different formats.
We'll also need something like PtsTimestampAdjuster to share between
separated audio and WebVTT tracks, which also contain PTS timestamps
that are aligned, and will need to share a common adjustment.
Issue: #692
- Don't allow "nothing has changed" optimization in the case
that only styling has changed (TextUtils.equals will return
true in this case, but we shouldn't optimize).
- Add functionality to suppress embedded styling; seems useful
to have.
- Added "this." for clarity.
When a live stream ends, what typically happens is that the manifest
is refreshed and the refreshed version is not marked as live/dynamic.
When this happens we:
1. Don't want the duration of the track to change.
2. Still want to consider the possibility that we may have fallen behind
the live window.
3. Don't want to allow futher manifest refreshes.
This change uses the right thing in the right place.
- Admit we don't know the mime type (using unknown mime types) rather
than passing the container mime type.
- Pass the correct mime type for opus, vp9 and vp8, and remove the incorrect
container checks in the corresponding extensions.
- Fix building with APP_ABI=all by configuring for all architectures.
- Keep vpx_dsp which is required for building successfully.
- Use perl -pi -e not sed, for building on Macs.
- With this change, you can select from the individual video formats in
the demo app, as well as the regular "auto" (adaptive) track.
- DashRendererBuilder no longer needs to create MultiTrackChunkSource
instances for the multiple tracks to be exposed.
I think such manifests are invalid, and I haven't seen any examples,
but given it's trivial to fill in the duration if the periods define
durations, it seems worth being robust.
- It's not possible to determine a period's duration just from the
corresponding Period element in a DASH manifest. It's necessary
to look at the start time of the next period (or the duration of the
manifest for the last period) to determine how long a period is. We
don't currently do this in the parser, and hence set duration incorrectly.
We also set period start times incorrectly because we don't set it to
equal to sum of the durations of prior periods in the case where it's
not explicitly defined.
- We're currently propagating these (incorrect) values all over the place
through data-structures that we build when parsing the Period element.
- This CL removes this redundancy, storing only the start time of each
period in Period elements, and not propagating it elsewhere. It's then
used when required in DashChunkSource.
The following sequence was problematic:
1. See start of a cluster having not output a seek map. Decide
to seek for the cues. Enter CUES_STATE_BUILDING state.
2. Error occurs before seek map is output.
3. ExtractorSampleSource isn't prepared yet, so restarts from the
start of the stream.
4. See start of the same cluster having not output a seek map.
This time cuesState is CUES_STATE_BUILDING, so we just carry
on. We then fill the buffer with sample data, despite the
source not being prepared, at which point we get stuck.
It's unclear to me why cuesState needed three states, so I've rm'd
the BUILDING state. Step (4) above will now do the same thing as
in step (1). If the failure repeats, we'll eventually fail, which
is WAI.
