It's very unlikely any onQueueInputBuffer implementations are looking
at the subsample encryption data, but from a correctness perspective
we should be passing a buffer object that's self-consistent.
PiperOrigin-RevId: 311011246
FFmpeg requires input buffers to be sized larger than the size
of the data they contain. This is to allow optimized decoder
implementations that read data in fixed size chunks, without
the risk of such decoders reading beyond the end of the buffer.
Issue: #2159
PiperOrigin-RevId: 310946866
We currently use the playback position in the current window, not the
position in the window the event belongs to. This creates confusing
outputs, e.g, window=1, mediaPos=100, even if the position refers to
window 0.
issue:#7332
PiperOrigin-RevId: 310896908
The tts:textAlign property only applies to <p> elements, which
correspond 1:1 with ExoPlayer Cue objects, so we can use
Cue.textAlignment to store this info instead of encoding it in
the span-styled text.
This will mean that TTML subtitles used with
SubtitleView#setApplyEmbeddedStyles(false) will start respecting
the tts:textAlign properties from the source data (currently this
information is stripped when we remove all span styling). I think this
is working-as-intended, we respect alignment of other subtitle types
(e.g. WebVTT) when applyEmbeddedStyles=false. We also respect all other
'positioning' related properties in this case e.g. Cue.position and
Cue.line.
PiperOrigin-RevId: 310895499
*** Original commit ***
Rollback of 70273a0361
*** Original commit ***
Assert incoming buffers are little endian in the DefaultAudioSink.
***
***
PiperOrigin-RevId: 310889382
When operating the MediaCodec in asynchronous mode, we are seeing
NPEs raised from the DefaultAudioSink because output buffers are pushed
to the DefaultAudioSink with the DefaultAudioSink not configured yet.
This is possible to happen if an output buffer is passed with
MediaCodecAudioRenderer.processOutputBuffer() before an output format
change.
One possible code path to trigger this is when an output format change
is pending and we flush MediaCodec (e.g. for a seek): the callback is
waiting in the looper's queue but we ignore all currently queued
callbacks after a flush().
This commit checks for a pending output format change during a flush():
if one exists, and the next MediaCodec output callback right after the
flush() is an output buffer (and not a new output format), then the
pending output format is propagated first.
The only adapter that needs to change is the
AsynchronousMediaCodecAdapter which previsouly deleted all pending
callbacks immediately on flush(). The AsynchronousMediaCodecAdapter now
needs to also handle every enqueued callback in order to identify is
there's a pending output format change.
Testing: added unit tests for the new code. I have verified that if we
pass an output buffer to the audio renderer before the output format, it
will result on the specific NPE, but I cannot reproduce the base
scenario (an output format change is pending when flushing) on a real
device because we can't know if an output format is indeed pending.
PiperOrigin-RevId: 310885283
We currently propagate only ColorInfo, but propagating the whole Format
is generally useful (e.g., to get the frame-rate on the output side of
the decoder).
PiperOrigin-RevId: 310359650
This allows properties to propagate when switching view types
(e.g. bottomPaddingFraction).
It also allows the style-stripping code to be pushed up to SubtitleView
and therefore shared.
PiperOrigin-RevId: 310353534
Fixes AsynchronousMediaCodecBufferEnqueuerTest broken tests by
enqueueing input buffers that have previously been dequeued from the
MediaCodec.
The test assumes that the shadow MediaCodec implementation can dequeue
at least 10 input buffers before queueing them back. Although fragile,
it seems to work with the current robolectric shadow MediaCodec. This is
at the moment preferred compared to making the test more complicated.
PiperOrigin-RevId: 310325096
Some part of the audio pipeline in the DefaultAudioSink
(PCM processors) are expecting little endian buffers.
As a result, in order to behave like MediaCodec,
make sure the passthrough MediaCodec-bypass pipeline
also processes little endian output buffers.
PiperOrigin-RevId: 310172464
Previously the input format values were used,
but it could be incorrect if two format change were
occurring in quick successions.
PiperOrigin-RevId: 310142675
These methods operate on a thread-safe collection and are thus
inherently thread-safe. This simplifies some player setup configurations
where initial listeners are added on a background thread (e.g. when
using a dependency injection framework).
PiperOrigin-RevId: 310113181
Users of addTextOutput should instead query the current cues if they
need them. This is more consistent with how other listeners are handled.
PiperOrigin-RevId: 310112241
We currently have DecoderVideoRenderer and VideoDecoderRenderer, which
is very confusing! This one is package private, so we can rename it to
remove some of the confusion.
Also fix some nullness issues.
PiperOrigin-RevId: 309964088
In passthrough MediaCodec is not used except if
the format has a DRM.
Nevertheless the code was still requiring that a
passthrough decoder be present even if it was not going to be
used (aka no drm).
PiperOrigin-RevId: 309947271
- Fix DecoderAudioRenderer to re-init codec if the DRM session changes.
- Add canKeepCodec to DecoderVideoRenderer. Previously it was assumed
that the decoder could be re-used, but this will not be true in all
cases for FfmpegVideoRenderer.
Issue: #7079
PiperOrigin-RevId: 309935278
If the condition isn't fulfilled, they currently block until the
test runner times out the test. Our usual approach is to timeout
in the test itself so that the error message is clearly showing the
blocked condition.
Also clean-up some documentation.
PiperOrigin-RevId: 309930198
Now that MediaCodec is not use in passthrough, no
MediaCodec should be created in this mode.
Additionally, do not instantiate a MediaCodec in passthrough
#exo-offload
PiperOrigin-RevId: 309916131
DownloadManager doesn't know enough about the Downloader implementations to
know that interrupting the thread is the right thing to do. In particular,
if a Downloader implementation wants to delegate work to additional worker
threads, then it will probably not want its main thread to be interrupted
on cancelation. Instead, it will want to cancel/interrupt its worker threads,
and keep its main thread blocked until work on those worker threads has
stopped (download() must not return whilst the Downloader is still touching
the cache).
This change moves control over what happens to the individual Downloader
implementations.
Issue: #5978
PiperOrigin-RevId: 309419177
- Stop throwing InterruptedException from CacheUtil. When a CacheUtil operation
throws or returns, the caller should always check its own state to determine
whether they canceled the operation. If a caller is trying to catch
InterruptedException separately to IOException to do something different in
that case, they're probably doing the wrong thing. So it's simpler, and probably
less error prone, just to throw an IOException in the case of interruption.
- Throwing InterruptedIOException is also consistent with what our Extractor and
DataSource implementations do.
Issue: #5978
PiperOrigin-RevId: 309411556
We keep an index hint for the next pending player message. This hint
wasn't updated correctly when messages are removed due to a timeline
update.
This change makes sure to only use the hint locally in one method so
that it doesn't need to be updated anywhere else and also adds the "hint"
suffix to the variable name to make it clearer that it's just a hint and
there are no guarantees this index actually exists anymore.
issue:#7278
PiperOrigin-RevId: 309217614
