Adjusted the bottom layout of StyledPlayerControlView :
- Enlarged bottom button's height to make tapping easier.
- Extended greyed background area to upper edge of seekbar.
- Gave padding between bottom edge of the overall layout and bottom buttons.
- Reduced horizontal margins between bottom buttons.
PiperOrigin-RevId: 336041160
`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
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
This test is intended to check that DefaultLoadControl will cause
playback to fail as "stuck buffering" rather than OOM-ing, in the
case that its target buffer size is reached and playback still
hasn't started.
Unfortunately, the target buffer size is ~130MB, and when running
on some setups an OOM actually ends up happening before this much
memory is allocated.
This change makes the target buffer size much smaller to avoid the
problem.
PiperOrigin-RevId: 331748208
This may remove available memory from other tests running in the same
process. Instead, create the huge buffer when needed so it can be GCed
immediately.
PiperOrigin-RevId: 330960844
When passing in ExtractorFactory instances to SimpleExoPlayer.Builder or
DefaultMediaSourceFactory, we currently need to pass in one other
instance (RenderersFactory or DataSource.Factory), that developers will
often set to its default. To avoid specifying these defaults, these new
convience methods allow to just set the ExtractorsFactory if required.
PiperOrigin-RevId: 330908002
This allows to customize extractor flags more easily when setting up the player.
In addition, we need to provide a way to pass in the ExtractorFactory through
the constructor chain starting in SimpleExoPlayer so that removing the
DefaultExtractorsFactory is possible for R8.
PiperOrigin-RevId: 330472935
- Use a setter, which is consistent with how other optional
components are passed.
- Remove nesting where a provider provides another provider.
Since AdSupportProvider then only provides one thing, it
can be renamed to AdsLoaderProvider, which more clearly
expresses what it provides.
PiperOrigin-RevId: 330396334
- Prevent buffering when clicking ffwd button at the end of stream
- Set VR button disabled when listener is not registered
PiperOrigin-RevId: 330039336
In maybeInitCodecWithFallback, it caches availableCodecInfos with mediaCryptoRequiresSecureDecoder and inputFormat as inputs, and won't clear it if shouldInitCodec is false, resulting in a case where availableCodecInfos is not null and codec is null.
When we have a new format, it's reasonable to clear availableCodecInfos if codec is null. Otherwise we might not be able to properly initialize a new codec.
PiperOrigin-RevId: 329971796
This CL fixes two bugs:
- Play/pause button toggling looked inconsistent when playback fails.
When player state goes into idle, play button should dispatch
playwhenready again.
- Clicking play button at the end of stream should restart playback.
But previously it changed playwhenready state and so playback has
been paused. This CL fix it.
PiperOrigin-RevId: 329675660
1. Add EventLogger right away in PlayerActivity, else it doesn't log
playWhenReady being initially set to true.
2. Remove EventLogger logging for the audio position advancing. It's
redundant with isPlaying logging unless you're very specifically
interested in the timing difference.
3. Remove unnecessary comment in Player.
4. Fix Timeline Javadoc.
PiperOrigin-RevId: 328983944
In 2.11.2 to 2.11.5, we considered all AAC streams as consisting
only of sync samples. In 2.11.6+, we considered no AAC streams as
consisting of sync samples, because the property is not guaranteed
specifically for xHE-AAC. This will have caused a small regression
is seek speed for some types of media.
This change brings back the optimization for AAC, specifically
excluding only xHE-AAC (and cases where we don't know what type of
AAC we're dealing with).
PiperOrigin-RevId: 328950697
To play slow motion streams where the audio has been recorded at
slower speeds, it is necessary to be able to resample (rather than
time-stretch) the audio. This change undeprecates back the previously
deprecated PlaybackParameters class to allow apps to set pitch.
PiperOrigin-RevId: 328703116
We currently always reset everything if playingPeriod != readingPeriod.
However, this is only needed when the pausing is actually required, i.e.,
if the feature is enabled and we are in the last period of the window.
PiperOrigin-RevId: 328141242
Currently the audio renderer can become ready before the AudioTrack
actually has enough data to play something, which means that the
player may transition to the ready state before audio starts
playing. This makes the player's current state transition not very
useful for detecting when audio actually starts playing.
This change adds a new event to notify apps when the audio position
is increasing after a pause or seek/flush/reset event, and includes
an estimate of the system time at which audio playout started.
Issue: #7577
PiperOrigin-RevId: 327810040
