1. For codecs that change timestamps, we need to use greater
or equal instead of just equal for comparison.
2. We should only make this comparison once a value has been
set.
3. The largest queue timestamp isn't updated before using it
for this detection, meaning that we also mark the
second-to-last sample as the last one.
PiperOrigin-RevId: 550901978
We currently pass in the time at which the stream originally started,
but newly enabled renderers should get the current playback position
instead.
PiperOrigin-RevId: 550894630
Instead of `text/x-exoplayer-cues`, we will use `application/x-media3-cues`.
The prefix should be `application` not `text` since the encoded form is arbitrary bytes, not necessarily text. The name should not reference `exoplayer`, since the Media3 Extractors (which are not part of `exoplayer`) produce this format.
PiperOrigin-RevId: 550181852
`TtmlDecoder` which used to be `SimpleSubtitleDecoder` will now be called `TtmlParser` and implement SubtitleParser interface. For backwards compatibility, we will have the same functionality provided by `DelegatingSubtitleDecoder` backed-up by a new `TtmlParser` instance.
PiperOrigin-RevId: 549700490
This tracker aims to replicate the behavior of a specific codec to
ensure MediaCodecRenderer correctly detects stream and output
format transitions. The class was needed because MediaCodecRenderer
made assumptions about codec behavior this codec did not fulfil (in
particular, changing timestamps and number of samples).
Since then, MediaCodecRenderer was made more robust to this kind of
codec behavior in general and currently has no assumptions that
require any special handling of this codec. This means we can remove
the workaround completely.
PiperOrigin-RevId: 549610989
This is no longer flaky because WebVTT subtitles are decoded on the
loading thread (enabled in this test with
`defaultExractorsFactory.setTextTrackTranscodingEnabled(true)` - and
supported for WebVTT since f0f24aa0d4).
PiperOrigin-RevId: 549594291
The class tries to be flexible to support as many different input
and codec behavior combinations as possible. But so far it didn't
spell out its remaining assumptions and explicit non-assumptions,
making it hard to know which behavior to rely on.
PiperOrigin-RevId: 549589347
Updated `ExoTrackSelection` to provide the most recent bitrate estimate, enabling the inclusion of measured throughput (mtp) as a CMCD-Request field in Common Media Client Data (CMCD) logging.
Additionally, made changes to the `checkArgument` methods in `CmcdLog` to prevent the use of default values in certain cases.
#minor-release
PiperOrigin-RevId: 549369529
`WebvttDecoder` which used to be `SimpleSubtitleDecoder` will now be called `WebvttParser` and implement `SubtitleParser` interface.
For backwards compatibility, we will have the same functionality provided by `DelegatingSubtitleDecoder` backed-up by a new `WebvttParser` instance. `WebvttSubtitle` will still be used behind the scenes to handle overlapping `Cues`.
PiperOrigin-RevId: 549298733
The end-to-end test output for the overlapping SRT and SSA subtitles
is currently incorrect. They will be fixed in a future change that
updates `TextRenderer` to support this overlap.
The 'extra' samples visible in the extractor test output files are
'empty cue list' samples produced by `SsaParser`. They will go away
when this implementation is updated to remove this behaviour and rely
on `CuesWithTiming.durationUs` instead (the 'empty list' behaviour is
not required by the `SubtitleParser` interface).
PiperOrigin-RevId: 549264593
*** Original commit ***
Rollback of b69b33206e
*** Original commit ***
Mark output sample as decode-only based on start time
We currently do the same check on the input timestamps and
expect the output timestamps to match. Some codecs produce
samples with modified timestamps and the logic is a lot safer
when the comparison with the start time is done on the output
side of the codec.
Issue: google/ExoPlayer#11000
***
***
PiperOrigin-RevId: 549019403
This ensures the DownloadService stays functional on Android 14
where defining this type is required. On Android 14 and above,
the app also needs to define the DATA_SYNC permission, which is
added to the demo app as well. In the future, this service type
will no longer be supported and DownloadService needs to be
rewritten with another background scheduling framework.
Issue: google/ExoPlayer#11239
PiperOrigin-RevId: 548994842
This was done because it was deemed correct to only start at timestamp
zero when the code was originally written. However, in case of
prerolling from a keyframe, many samples will get the same timestamp,
which is not correct and interferes with downstream logic
that deals with timestamps.
PiperOrigin-RevId: 548986160
Reading a discontinuity from a media period indicates that a position
reset is required. As part of this event, the media period may need
further loading (e.g in a MergingMediaPeriod where one stream reported
a discontinuity and the other need to reload from this position).
This currently fails if the media periods was already fully loaded and
we started loading further items in the playlist. As a result, playback
is stuck forever. We can fix this by detecting that further loading is
needed and resetting the loading period to the current one.
The existing MergingPlaylistPlaybackTest already covers this case
reliably, because it combines all the right preconditions (merging
source, clipping to get a discontinuity and a playlist).
PiperOrigin-RevId: 548735177
This is a step towards adding general support for overlapping
subtitles in these formats (and others), both muxed and sideloaded:
* Issue: google/ExoPlayer#10295
* Issue: google/ExoPlayer#4794
This change adds these files to the end-to-end playback tests too, but
the subtitle track is currently disabled because renderer-side subtitle
parsing causes flaky tests (due to an uncontrolled thread in
`SimpleSubtitleDecoder`). The subtitle track will be re-enabled in
a follow-up change when loading-side subtitle parsing is added (so the
tests will no longer be flaky). At this point the overlapping subtitles
**still** won't be supported end-to-end, but a second change will
resolve this will changes in `TextRenderer` - which will change the
end-to-end playback dumps to reflect the overlapping subtitles.
PiperOrigin-RevId: 548705032
The streams return end-of-input if they read no samples, but know that
they are fully buffered to at least the clipped end time. This helps to
detect the end of stream even if there are no new buffers after the end
of the clip (e.g. for sparse metadata tracks).
The race condition occurs because the buffered position is evaluated
after reading the sample. So between reading "no sample" and checking
the buffered position, the source may have loaded arbitrary amounts
of data. This may lead to a situation where the source has not read
all samples, reads NOTHING_READ (because the queue is empty) and then
immediately returns end-of-stream (because the buffered position
jumped forward), causing all remaining samples in the stream to be
skipped. This can fixed by moving the buffered position check to
before reading the sample, so that it never exceeds the buffered
position at the time of reading "no sample".
#minor-release
PiperOrigin-RevId: 548646464
Also re-use the `CuesWithTimingSubtitle` implementation (previously a
private class inside `DelegatingSubtitleDecoder`) in `ExoPlayerCuesDecoder`.
PiperOrigin-RevId: 548612040
It will act similarly to `SubtitleDecoderFactory`, but return parsers instead of decoders. In turn `SubtitleDecoderFactory.createDecoder()` cab wrap those parsers with `DelegatingSubtitleDecoder`.
PiperOrigin-RevId: 548528054
`PgsDecoder` which used to be `SimpleSubtitleDecoder` will now be called `PgsParser` and implement `SubtitleParser` interface. For backwards compatibility, we will have the same functionality provided by `DelegatingSubtitleDecoder` backed-up by a new `PgsParser` instance.
PiperOrigin-RevId: 548520549
`DvbDecoder` which used to be `SimpleSubtitleDecoder` will now be called `DvbParser` and implement `SubtitleParser` interface. There was, however, already a `DvbParser`, used by `DvbDecoder` behind the scenes. Hence, the refactoring only requires the existing `DvbParser` to adhere to the new `SubtitleParser` interface.
For backwards compatibility, we will have the same functionality as `DvbDecoder` provided by `DelegatingSubtitleDecoder` backed-up by a new `DvbParser` instance, available from the `SubtitleDecoderFactory`.
PiperOrigin-RevId: 548155759
`Tx3gDecoder` which used to be `SimpleSubtitleDecoder` will now be called `Tx3gParser` and implement `SubtitleParser` interface. For backwards compatibility, we will have the same functionality provided by `DelegatingSubtitleDecoder` backed-up by a new `Tx3gParser` instance.
PiperOrigin-RevId: 548144492
Add Ogg ID Header and Comment Header Pages to the Ogg encapsulated Opus for offload playback. This further matches the RFC 7845 spec and provides initialization data to decoders.
PiperOrigin-RevId: 548080222
These tests allow to verify the samples sent for decoding,
when decoders are reset, which samples are dropped as decode-only
for video and which samples are sent to the AudioTrack for playback.
The test exercises all combinations of merges where audio or video
is the primary track and where audio, video or both are clipped.
PiperOrigin-RevId: 548061254
These tests allow to verify the samples sent for decoding,
when decoders are reset, which samples are dropped as decode-only
for video and which samples are sent to the AudioTrack for playback.
The test exercises all combinations of clipping transitions for
sources that are either clipped at the start, the end, or both.
PiperOrigin-RevId: 547730824
When a renderer is pre-enabled (while another playback is still
ongoing), we pass mayRenderStartOfStream=false to Renderer.enable.
This ensures we don't show any first frames while the previous media
is still playing.
Currently, we never tell the renderer when we actually stop playing
the previous media so that it could render the start of the stream,
because we allow this as soon as the renderer is in STATE_STARTED and
we assume that we have to be in STATE_STARTED to make this stream
transition.
While this assumption is true, there are also cases where we can't
start the renderers because they are not ready yet and the video
renderer can't become ready because it didn't render its first frame.
This effectively blocks playback forever.
The most direct way of solving this, is to tell the renderer that
playback has transitioned and that it is now allowed to render the
start of the stream. This means it can never get blocked as described
above.
PiperOrigin-RevId: 547727347
`Mp4WebvttDecoder` which used to be `SimpleSubtitleDecoder` will now be called `Mp4WebvttParser` and implement `SubtitleParser` interface. For backwards compatibility, we will have the same functionality provided by `DelegatingSubtitleDecoder` backed-up by a new `Mp4WebvttParser` instance.
PiperOrigin-RevId: 547248157
For sync-sample-only formats, we have an optimization to drop all buffers
with less than the start time when writing them to the queue.
For the same formats, if we set a new start time (=seek), we only seek
to the buffer at or before the start time. This means the first sample
in the queue is different depending on whether we seek to a start time
or set a start time and then write samples. This is inconsistent and
effectively means the first sample depends on a race condition between
the Loader thread (writing samples) and the playback thread (attempting
an initial seek in the already loaded samples).
The effect of this inconsistency is that we have to decode one sample
we don't need (and could have skipped) and that some tests become flaky
if the test setup runs into the mentioned race condition.
The fix is to change the SampleQueue seek method to also seek to
a sample at or after the specified time, to align the behavior to the
case where we write the same samples to an empty queue.
The change also clarifies the Javadoc of
MimeTypes.allSamplesAreSyncSamples to note that this should really only
return true if the samples have no "duration" that matters. Otherwise,
we could reasonably return true for most subtitle formats although it
would break subtitle display because we'd remove samples that start
before the seek time.
PiperOrigin-RevId: 547189941
Also parse the PCM encoding for lpcm in MP4, and update `MatroskaExtractor`
similarly.
Tested manually in the demo app using an MP4 with 24-bit big endian audio.
PiperOrigin-RevId: 546878505
Some adjustments to the test to make it more correct and prevent it
from becoming flaky:
- Use separate output dump files per test setup. Once we add more data
to these files, they are not guaranteed to be the same anymore.
- Use a seek position that is actually behind the midroll as described
in the test setup.
- Change ad insertion position to ensure the ad group duration doesn't
exceed the underlying media duration.
- Add a wait for isLoading to ensure the late insertion of an ad group
happens consistently at the same processing stage.
PiperOrigin-RevId: 546825183
This changes all MediaSources in our library to allow updates to
their MediaItems (if supported).
Issue: google/ExoPlayer#9978
Issue: androidx/media#33
PiperOrigin-RevId: 546808812
`SubripDecoder` which used to be `SimpleSubtitleDecoder` will now be called `SubripParser` and implement `SubtitleParser` interface. For backwards compatibility, we will have the same functionality provided by `DelegatingSubtitleDecoder` backed-up by a new `SubripParser` instance.
PiperOrigin-RevId: 546538113
`SsaDecoder` which used to be `SimpleSubtitleDecoder` will now be called `SsaParser` and implement `SubtitleParser` interface. For backwards compatibility, we will have the same functionality provided by `DelegatingSubtitleDecoder` backed-up by a new `SsaParser` instance.
PiperOrigin-RevId: 546336035
`DelegatingSubtitleDecoder` is a `SimpleSubtitleDecoder` that delegates to a `SubtitleParser` instance (e.g. future implementations like `WebvttParser`, `SubripParser`, `SsaParser`, `DvbParser` etc)
It will be in the `exoplayer` package, rather than `extractor` and only be used in the decoding flow which happens after SampleQueue (and to be deprecated). When this decoding flow is deprecated and removed, the class can be later deleted.
PiperOrigin-RevId: 546317528
This makes tests more realistic because the returned value matches
the rest of the simulated test time.
It also prevents test flakiness in (yet to be written) tests that
may not correctly advance the playback time in the position tracker.
PiperOrigin-RevId: 546011842
When selecting progressive and HLS tracks, we currently check if
we can either seek in the existing samples or are starting from the
beginning of the stream. In both cases, we don't need to reload the
stream and can continue reading.
Seeking to the beginning isn't side-effect free though because it
also sets the startTimeUs to zero. Whether a seek to the beginning
is successful also depends on whether we already loaded a sample or
not. This mean that the startTimeUs value is set (or not set) based
on the speed of the Loader thread even for the same input starting
from the beginning. This race condition means the actual samples
we write to the stream may differ if the stream has initial samples
with negative timestamps.
We can avoid this race condition by checking if the queue is empty
first, so that we only call seekTo if really needed.
PiperOrigin-RevId: 546010951
Robolectric writes warnings to the log output because the Surfaces
we create are not released and pollute the test environment. This
causes performance issues if tests are run repeatedly.
PiperOrigin-RevId: 545906757
We have the optimization to skip buffers if the release time is
exactly the same as the one for the previous buffer. This makes
sense under the assumption that these buffers get released to
a visible Surface and will be ignored anyway.
However, it's also helpful to provide a customization option to not
do this for cases where the outputting MediaCodecAdapter is not
directly talking to a visible Surface or for tests where we can't
fully control the vsync timing of the Surface and want to ensure
we output all samples that are meant to be shown.
PiperOrigin-RevId: 545906113
This makes tests more realistic because the returned value matches
the rest of the simulated test time.
It also prevents test flakiness in (yet to be written) tests that
may accidentally drop output buffers or calculate the wrong values.
PiperOrigin-RevId: 545690008
Upon track transition of offloaded playback of gapless tracks, the framework will reset the playback head position. The AudioTrackPositionTracker must be made to expect the reset and cache accumulated sum of rawPlaybackHeadPosition.
#minor-release
PiperOrigin-RevId: 545602979
This allows MediaSources to accept MediaItem updates after creation.
This CL adds the handling and plumbing logic in `ExoPlayerImpl`,
`ExoPlayerImplInternal`, `MediaSourceList` and `MaskingMediaSource`.
It also updates all forwarding/wrapping sources to forward these calls
to their wrapped instance.
The actual functionality is only added to `FakeMediaSource` instances in
tests so far.
PiperOrigin-RevId: 545450210
This plumbs a duration through `SampleQueue` which will make it easier
to handle transcoding muxed subtitles from e.g. SubRip to
`text/x-exoplayer-cues`.
This change is a no-op to the end-to-end behaviour of ExoPlayer because
currently we only support parsing sideloaded subtitles before
`SampleQueue`, and by adding the duration we don't affect the cues that
are ultimately output by `Player.Listener.onCues` (as shown by no change
to the golden files for `WebvttPlaybackTest` in this commit).
I considered making `CuesWithStartTimeAndDuration` implement
`Bundleable` (and deleting `CueEncoder/Decoder`) but decided against
it because we are deliberately not encoding `startTimeUs` (since that's
encoded as the sample time in `SampleQueue`). I also considered
introducing another type that only has `List<Cue>` and `durationUs`
fields, but it didn't seem necessary, since we want `startTimeUs`
everywhere else (except inside `SampleQueue`).
PiperOrigin-RevId: 545226847
