I added the TS playback tests for these assets without adding support
for the relevant MIME types to ShadowMediaCodec.
Also remove test assets with more than 2 audio channels - this isn't
currently supported by ShadowAudioSystem. I'll re-add these when support
is available.
PiperOrigin-RevId: 338023290
The available duration used a "live edge" that was calculated in
the previous iteration and was thus quite old. Also it also used
the end of the last available segment, but the actually available
duration for buffering needs to be clamped to the current live edge
for low-latency streams.
Issue: #4904
PiperOrigin-RevId: 337812621
ExoPlayerImpl and CastPlayer repeat the same logic. Moving the listener
and event handling to a common util class allows to reuse the same code
and add unit tests for this logic.
The change is a functional no-op.
PiperOrigin-RevId: 337812358
The build needs to remove some duplicate dependencies to work again.
Also replace a deprecated API usage with the non-deprecated equivalent
and merge the two Blaze target into one to simplify Gradle file.
PiperOrigin-RevId: 337812099
`subtitle` is only guaranteed to be non-null if
`nextSubtitleEventIndex != C.INDEX_UNSET`. The null check added in
0efec5f6c1
was too early.
Issue: #8017
PiperOrigin-RevId: 334777742
This was broken by 74a9d8f680
because DashManifestParser switched to setting Format.sampleMimeType to
text/vtt while SubtitleDecoderFactory was still expecting
application/x-mp4-vtt. This change teaches SubtitleDecoderFactory to
check both Format.containerMimeType and Format.sampleMimeType.
I'll investigate a follow-up change to remove
MimeTypes.APPLICATION_MP4VTT completely (it's currently still used in
AtomParsers).
Issue: #7985
PiperOrigin-RevId: 334771672
When I moved ParsableByteArray#data behind a getter I replaced some
assignments with calls to reset(byte[]):
ce2e6e2fd6
reset(byte[]) deliberately sets `limit` to `data.length`, in order to
handle cases that were reassigning `data` but not updating `limit`.
However OggPacket was already using `limit` to track where to write
'new' data into the array, so changing `limit` to `data.length` caused
us to try and write new data beyond the end of the array.
I looked at other uses of reset(byte[]) in ce2e6e2fd6
and condluded the only other usage in MatroskaExtractor is legit and
shouldn't be updated like this (because MatroskaExtractor previously
*wasn't* correctly updating/maintaining `limit`).
Issue: #7992
PiperOrigin-RevId: 334601586
Non-realtime AudioTrack playback speed was not taken into account when
extrapolating the old mode's position, causing the position not to
advance smoothly.
This should be a no-op when not using AudioTrack playback params for
speed adjustment.
Issue: #7982
PiperOrigin-RevId: 334151163
On receiving a fetch error for an ad that would otherwise play based on an
initial/seek position, the pending content position wasn't cleared which meant
that position reporting was broken after a fetch error. Fix this by always
clearing the pending position (if there was a pending position that will have
triggered the fetch error).
Also deduplicate the code for handling empty ad groups (fetch errors)
and ad group load errors.
Issue: #7956
PiperOrigin-RevId: 334113131
This issue has been observed on a test app stress
testing setEndOfStream.
The issue has not been observed on ExoPlayer,
probably due to timing differences, but it is fixed
preventively.
#exo-offload
PiperOrigin-RevId: 333472136
This seems to be an exact copy of sample.adts. Update the test to use
the same sample but just output to a different dump file.
PiperOrigin-RevId: 333469714
We have a workaround for uneven sample stream durarions in playlists that
assumes a renderer allows playback if it's reading ahead or waiting for
the next stream.
652c2f9c18 changed this logic to no longer require to
wait until the next stream is prepared due to a change in how we advance
media periods in the queue. However, the code falsely still requires the
next stream to exist (even if it's not prepared). This can cause a stuck
buffering state when the difference in the duration of the streams is more
than what we buffer ahead because we never create the next stream in such
a case.
Note: DefaultMediaClock.shouldUseStandaloneClock has roughly the same logic
and also doesn't require the next stream to be present.
Also fix a test that seemed to rely on this stuck buffering case to test
stuck buffering detection. Changed the test to not read the end of stream
to ensure it runs into the desired stuck buffering case.
Issue:#7943
PiperOrigin-RevId: 333050285
Without this patch, playback would be frozen indefinitely
until the user manually pauses and unpauses it.
This has the side effect of disabling offload until
the next stop due to the workaround of
disabling offload when it encounters a failure.
As an audio server crash is considered very
infrequent, especially in stable conditions like
an audio only playback, it is unlikely that disabling
offload is an issue.
PiperOrigin-RevId: 332857094
I didn't copy-paste the whole of
https://github.com/google/guava/wiki/UsingProGuardWithGuava because
this line seems relevant based on our current usage.
Lots of that file seems to relate to classes that are strongly
discouraged on Android:
https://github.com/google/guava/wiki/Android#specifics
I've only added this to the `common` module, since everyone that uses
ExoPlayer must depend on that. This avoids duplicating this line into
every module that has a Guava dependency.
Also remove some other warning suppressions that are defined in both
`core` and `common`.
Issue: #7904
PiperOrigin-RevId: 332203086
