Users of this class may run into these assertions when creating the
State and they need to check the source code to understand why
the State is invalid. Adding error messages to all our correctness
assertions helps to understand the root cause more easily.
PiperOrigin-RevId: 496875109
(cherry picked from commit b7e887a58d)
These are the remaining setter operations. They all share the same
logic that handles playlist and/or position changes. The logic to
create the placeholder state is mostly copied from ExoPlayerImpl's
maskTimelineAndPosition and getPeriodPositonUsAfterTimelineChanged.
PiperOrigin-RevId: 496364712
(cherry picked from commit 09d37641d1)
The tunneling callbacks are sent via Handler messages and may be
handled after the codec/surface was changed or released.
We already guard against the codec/surface change condition by
creating a new listener and verifying that the current callback
happens for the correct listener instance, but we don't guard
against a released codec yet.
PiperOrigin-RevId: 495882353
(cherry picked from commit 5e23b8bfd5)
Some Player methods operate relative to existing indices in the
playlist (add,remove,move,seek). As these operations may be issued
from a place with a stale playlist (e.g. a controller that sends
a command while the playlist is changing), we have to handle out-
of-bounds indices gracefully. In most cases this is already
documented and implemented correctly. However, some cases are not
documented and the existing player implementations don't handle
these cases consistently (or in some cases not even correctly).
PiperOrigin-RevId: 495856295
(cherry picked from commit a1c0b10482)
The `MediaItem` instances in the following cases are not actually empty but acts as a placeholder. `EMPTY_MEDIA_ITEM` can also be confused with `MediaItem.EMPTY`.
PiperOrigin-RevId: 495843012
(cherry picked from commit 74559b4a18)
Improves the time taken to construct `playerInfo` from its bundle from ~450 ms to ~400 ms. Each `MediaItem` inside `Timeline.Window` contains `MediaMetadata` and hence is a good candidate for bundling optimisations. There already exists a test to check all parameters for null values when unset.
PiperOrigin-RevId: 495614719
(cherry picked from commit 8dea624c98)
This simplifies some position tracking needs for an app implementing
SimpleBasePlayer.
- The period index can always be derived from the media item index
and the position. So there is no need to set it separately.
- The media item index can be left unset in the State in case the app
doesn't care about the value or wants to set it the default start
index (e.g. while the playlist is still empty where UNSET is
different from zero).
- Similarly, we should allow to set the content position (and buffered
position) to C.TIME_UNSET to let the app ignore it or indicate the
default position explictly.
PiperOrigin-RevId: 495352633
(cherry picked from commit 91557ac9d4)
This ensures they are not accidentally triggered again when
the state is rebuilt with a buildUpon method.
PiperOrigin-RevId: 495280711
(cherry picked from commit fa5aaf958d)
This improves the time taken to construct PlayerInfo from bundle from ~600ms to ~450ms.
PiperOrigin-RevId: 495055355
(cherry picked from commit 7de47fe2a1)
isLoading is not allowed to be true when IDLE, so we have to set to
false when stopping in case it was set to true before.
PiperOrigin-RevId: 494975405
(cherry picked from commit e4f0b73aa3)
BasePlayer simplifies implementations by handling all the various
seek methods and forwarding to a single method that can then be
implemented by subclasses. However, this loses the information about
the concrete entry point used for seeking, which is relevant when
the subclass wants to verify or filter by Player.Command. This
can be improved by adding the command as a new parameter. Since
we have to change the method anyway, we can also incorporate the
boolean flag about whether the current item is repeated to avoid
the separate method.
PiperOrigin-RevId: 494948094
(cherry picked from commit 6e0f1f10b3)
Some Player methods like getting the Looper and adding listeners
were always allowed to be called from any thread, but this is
undocumented. This change makes the threading rules of these
methods more explicit.
Removing listeners was never meant to be called from another thread
and we also don't support it safely because final callbacks may
be triggered from the wrong thread. To find potential issues, we
can assert the correct thread when releasing listeners.
Finally, there is a potential race condition when calling addListener
from a different thread at the same time as release, which may lead to
a registered listener that could receive callbacks after the player is
released.
PiperOrigin-RevId: 493843981
(cherry picked from commit e9364b0f6e)
The folder type has a mix of information about the item. It shows
whether the item is browsable (type != FOLDER_TYPE_NONE) and
which Bluetooth folder type to set for legacy session information.
It's a lot clearer to split this into a boolean isBrowsable and
use the existing mediaType to map back to the bluetooth folder type
where required.
folderType is not marked as deprecated yet as this would be an API
change, which will be done later.
PiperOrigin-RevId: 493544589
(cherry picked from commit 9d059352cf)
This adds support for the release handling. To align with the
established behavior in ExoPlayer, the player can only call
listeners from within the release methods (and not afterwards)
and automatically enforces an IDLE state (without listener call)
in case getters of the player are used after release.
PiperOrigin-RevId: 493543958
(cherry picked from commit 3a66c28d4f)
The callback is currently triggered on the ExoPlayer playback thread
instead of the app thread that added the listener.
PiperOrigin-RevId: 492474405
(cherry picked from commit f3fc4fb973)
This inconsistency was exposed by an upcoming change to deprecate
`POSITION_UNSET` in favour of `INDEX_UNSET` because position is an
ambiguous term between 'byte offset' and 'media position', as shown
here.
PiperOrigin-RevId: 492470241
(cherry picked from commit 2f8cf947c7)
Discovered while investigating Issue: google/ExoPlayer#10823
Example stack trace with the previous code (I added the index value for
debugging):
```
playerFailed [eventTime=44.07, mediaPos=44.01, window=0, period=0, errorCode=ERROR_CODE_FAILED_RUNTIME_CHECK
androidx.media3.exoplayer.ExoPlaybackException: Unexpected runtime error
at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:635)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loopOnce(Looper.java:202)
at android.os.Looper.loop(Looper.java:291)
at android.os.HandlerThread.run(HandlerThread.java:67)
Caused by: java.lang.IllegalArgumentException: index=-1
at androidx.media3.common.util.Assertions.checkArgument(Assertions.java:55)
at androidx.media3.extractor.text.webvtt.WebvttSubtitle.getEventTime(WebvttSubtitle.java:62)
at androidx.media3.extractor.text.SubtitleOutputBuffer.getEventTime(SubtitleOutputBuffer.java:56)
at androidx.media3.exoplayer.text.TextRenderer.getCurrentEventTimeUs(TextRenderer.java:435)
at androidx.media3.exoplayer.text.TextRenderer.render(TextRenderer.java:268)
at androidx.media3.exoplayer.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:1008)
at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:509)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loopOnce(Looper.java:202)
at android.os.Looper.loop(Looper.java:291)
at android.os.HandlerThread.run(HandlerThread.java:67)
]
```
#minor-release
PiperOrigin-RevId: 492464180
(cherry picked from commit 5f6fde4d2a)
In some cases we split a test method, and in other cases we just add
line breaks to make the separation between arrange/act/assert more
clear.
PiperOrigin-RevId: 492182769
(cherry picked from commit 02fa8aa784)
This adds the forwarding logic for most setters in SimpleExoPlayer
in the same style as the existing logic for setPlayWhenReady.
This change doesn't implement the setters for modifying media items,
seeking and releasing yet as they require additional handling that
goes beyond the repeated implementation pattern in this change.
PiperOrigin-RevId: 492124399
(cherry picked from commit e598a17b36)
This better matches the terminology we use elsewhere in the Player
interface, where items inside the playlist are referred to as
"media item" and only the entire list is called "playlist".
PiperOrigin-RevId: 491882849
(cherry picked from commit 6c467590d0)
Use the bitrate of the audio format (when available) in
DefaultAudioSink.AudioTrackBufferSizeProvider.getBufferSizeInBytes() to
calculate accurate buffer sizes for direct (passthrough) playbacks.
#minor-release
PiperOrigin-RevId: 491628530
(cherry picked from commit e219ac21ae)
To support OPUS offload, we need to provide a few configuration values
that are currently not set due to the lack of devices supporting
OPUS offload.
PiperOrigin-RevId: 491613716
(cherry picked from commit 4cf877b814)
The list of charsets is already hard-coded, and using `Charset` types
ensures they will all be present at run-time, hence we will never
encounter an 'unsupported' charset.
PiperOrigin-RevId: 491324466
(cherry picked from commit 043546a034)
Our FakeClock generally makes sure that playback tests are fully
deterministic. However, this fails if the test uses blocking waits
with clock.onThreadBlocked and where relevant Handlers are created
without using the clock.
To fix the flakiness, we can make the following adjustments:
- Use TestExoPlayerBuilder instead of legacy ExoPlayerTestRunner
to avoid onThreadBlocked calls. This also makes the tests more
readable.
- Use clock to create Handler for FakeVideoRenderer and
FakeAudioRenderer. Ideally, this should be passed through
RenderersFactory, but it's too disruptive given this is a
public API.
- Use clock for MediaSourceList and MediaPeriodQueue update
handler.
PiperOrigin-RevId: 490907495
(cherry picked from commit 7d62943bcd)
Format expects the values of `averageBitrate` and `peakBitrate` in bps and the value fetched from AC3SpecificBox and EC3SpecificBox is in kbps.
PiperOrigin-RevId: 490756581
(cherry picked from commit 67955e0ce3)
*** Original commit ***
Rollback of 01eddb34f5
*** Original commit ***
Parse and set `peakBitrate` for Dolby TrueHD(AC-3) and (E-)AC-3
#minor-release
***
***
PiperOrigin-RevId: 490707234
(cherry picked from commit 8c91a31ced)
*** Original commit ***
Parse and set `peakBitrate` for Dolby TrueHD(AC-3) and (E-)AC-3
#minor-release
***
PiperOrigin-RevId: 490570517
(cherry picked from commit ea3552c1a0)
This change includes a change in the `IMediaController.aidl` file and needs
to provide backwards compatibility for when a client connects that is of an older or
newer version of the current service implementation.
This CL proposes to create a new AIDL method `onPlayerInfoChangedWithExtensions`
that is easier to extend in the future because it does use an `Bundle` rather than
primitives. A `Bundle` can be changed in a backward/forwards compatible way
in case we need further changes.
The compatibility handling is provided in `MediaSessionStub` and `MediaControllerStub`. The approach is not based on specific AIDL/Binder features but implemented fully in application code.
Issue: androidx/media#102
#minor-release
PiperOrigin-RevId: 490483068
(cherry picked from commit f262e9132b)
ExoPlayer is unable to detect the presence of subtitle tracks in some
MPEG-TS files that don't fully declare them. It's possible for a
developer to provide the list instead, but doing so is quite awkward
without this helper method. This is consistent for how
`DefaultExtractorsFactory` allows other aspects of the delegate
`Extractor` implementations to be customised.
* Issue: google/ExoPlayer#10175
* Issue: google/ExoPlayer#10505
#minor-release
PiperOrigin-RevId: 490214619
(cherry picked from commit 4853444f0d)
This adds the full Builders and State representation needed to
implement all Player getter methods and listener invocations.
PiperOrigin-RevId: 489503319
(cherry picked from commit b81cd08271)
When estimating the AudioTrack min buffer size, we must use a PCM
frame of 1 when doing direct playback (passthrough). The code was
passing -1 (C.LENGTH_UNSET).
PiperOrigin-RevId: 489238392
(cherry picked from commit d9d716869b)
They are called from the system only and don't need to be exported
to be visible to other apps.
PiperOrigin-RevId: 489210264
(cherry picked from commit c1fd03df74)
The method allows clients to specify a pre-existing thread
to use for playback. This can be used to run multiple ExoPlayer
instances on the same playback thread.
PiperOrigin-RevId: 488980749
(cherry picked from commit 79b809b556)
Added new method to check if codec just functionally supports a format. Changed getDecoderInfosSortedByFormatSupport to use new function to order by functional support. This allows decoders that only support functionally and are more preferred by the MediaCodecSelector to keep their preferred position in the sorted list.
UnitTests included
-Two MediaCodecVideoRenderer tests that verify hw vs sw does not have an effect on sort of the decoder list, it is only based on functional support
Issue: google/ExoPlayer#10604
PiperOrigin-RevId: 487779284
(cherry picked from commit 1eb8a6b36e)
This tag is only understood by Dackka, which is used to generate the media3 javadoc.
PiperOrigin-RevId: 489233200
(cherry picked from commit 058cba95d4)
This better matches the callback name (onSurfaceSizeChanged) and
probably cause less confusion with getVideoSize.
PiperOrigin-RevId: 488669786
(cherry picked from commit 8438daca1f)
Util.getAudioTrackChannelConfig() maps a channel count to a
channel mask that is passed to AudioTrack. The method expected that
playback of 8-channel audio is possible from Android 5.1 and playback of
12-channel audio is only possible from Android 12L. However, there is no
restriction on the upper number of channels that can be passed to the
AudioTrack. google/ExoPlayer#10701 is an example where the audio decoder
outputs 12 channels on an Android 10.
This change removes the restrictions for 8 and 12 channels. Note, we still
do not support playback of arbitrary number of channels as it would require
further changes to DefaultAudioSink.
#minor-release
Issue: google/ExoPlayer#10701
PiperOrigin-RevId: 488659831
(cherry picked from commit 1b24e6fd14)
When we currently trigger the iteration finished event during the
release, we don't mark the event as triggered. This means that
someone can trigger another release from within the callback,
which then tries to resend the event.
Issue: google/ExoPlayer#10758
#minor-release
PiperOrigin-RevId: 488645089
(cherry picked from commit 3e5103a3e5)
We currently skip this calculation entirely, but it can be added by
calculating the window duration using the wrapped window's duration
and the provided AdPlaybackState.
Issue: google/ExoPlayer#10764
PiperOrigin-RevId: 488614767
(cherry picked from commit 20151b9930)
It's not clear to me why presubmit didn't catch this, I briefly
investigated but couldn't work it out - so I'm just going to fix
it and move on.
#minor-release
PiperOrigin-RevId: 487497827
(cherry picked from commit 13ee34facc)
This makes two fixes:
1. Remove `HlsSampleStreamWrapper.Callback` (package-private) from the
list of interfaces implemented by `HlsMediaPeriod` (`public`) and
move the implementation to a private inner class instead. This avoids
Metalava complaining about a public class that inherits from a
package-private type.
2. Reduce the visibility of
`RtpPayloadFormat.isFormatSupported(MediaDescription)` from `public`
to package-private. The `MediaDescription` type is already
package-private, so this method was already unusable outside the
package.
#minor-release
PiperOrigin-RevId: 487472781
(cherry picked from commit 9041d7b979)
This makes two types of fix:
1. Align parameter names on overridden methods where the superclass
has `@param` javadoc.
2. Use `@hide` on `protected final` methods that refer to package-private
types. This will hide these symbols from Dackka javadoc generation
but not (currently) from the artefacts distributed on Maven. These
methods are currently unusable outside their package anyway (e.g. by
external developers) because of the dependency on a package-private
type.
This also changes some HLS, SmoothStreaming, and IMA code where I've renamed
parameters of overridden methods to be consistent across the type
hierarchy.
#minor-release
PiperOrigin-RevId: 487472665
(cherry picked from commit 10c4a4dfc1)
Not setting the color info results in a missing "colr" box in the produced
container, under file/moov/trak/mdia/minf/stbl/stsd/hvc1. This means extractors
will not be able to find out the transcoded file is HDR.
In `Transformer`, this means it can't transcode this transcoded file, because
it currently relies on the container bearing HDR info to construct the
transcoding sample pipeline.
PiperOrigin-RevId: 487276712
(cherry picked from commit d6c8e3a8af)
In startTransformation method we were throwing UnsupportedEncodingException (IOException) when mediaItem with unsupported arguments is passed.
Changed this to IllegalArgumentException which seems more logical here.
PiperOrigin-RevId: 487259296
(cherry picked from commit 4598cc9248)
This logic is currently in the player renderers. With multi-asset, the
renderers will go into the AssetLoader, which shouldn't be responsible
for muxing.
PiperOrigin-RevId: 486860502
(cherry picked from commit d8754b6642)
Problem: We are initialising muxer as soon as we start the transformation. Now the startTransformation() method can be called from main thread, but muxer creation is an I/O operation and should be not be done on main thread.
Solution: Added lazy initialisation of muxer object. The actual transformation happens on background thread so the muxer will be initialised lazily from background thread only.
Another way was to provide an initialize() method on MuxerWrapper which will explicitly initialise muxer object but with this approach the caller need to call the initialise method before calling anything else. With current implementation the renderers are calling MuxerWrapper methods on various callbacks (Not sequentially) and also we are sharing same muxer with multiple renderers so It might become confusing for the caller on when to call the initialise() method. Also there are few methods on MuxerWrapper which dont really need muxer object. So in short it might make MuxerWrapper APIs more confusing.
Validation: Verified the transformation from demo app.
PiperOrigin-RevId: 486735787
(cherry picked from commit b10b4e6d46)
This should be necessary to ensure decoders see fewer errors.
Setting this resulted in removing native_dequeueOutputBuffer errors on OMX.MTK decoders for in-app tone mapping prototyping.
PiperOrigin-RevId: 486715941
(cherry picked from commit 0b7e5bbad2)
If there's an @param javadoc tag in a supertype then all overrides
of this method that don't also override the javadoc must use the same
parameter name.
PiperOrigin-RevId: 485857711
(cherry picked from commit b8e5d708fc)
Public methods may only refer to public types in their signature. This
change ensures that by switching to a public supertype everywhere.
PiperOrigin-RevId: 485568625
(cherry picked from commit 3fdfe585ff)
This change makes adding ad events in live streams more robust by allowing ad
groups to grow in number of ads if more ad events are received than initially
announced by the SDK.
With the IMA prefetch feature, an AdPod can grow in size in certain conditions
like from initially 2 ads to 4 ads being part of the ad group. With this change,
if an additional ad event arrives while the ad group is still being played,
the ad group is expanded. If the event arrives late and the ad group is already
completed, a new group is created for the remaining ads.
This also covers the case where we join the live stream while an ad is being
played and we missed at least one LOADED event from the SDK. Ads of the group
before the first LOADED event are ignored in such a case.
PiperOrigin-RevId: 484214760
(cherry picked from commit 136addf640)
From ANSI-CTA-608-E R-2014 section 8.4:
> When closed captioning is used on line 21, field 2, it shall conform
> to all of the applicable specifications and recommended practices as
> defined for field 1 services with the following differences:
> 1. The non-printing character of the miscellaneous control-character
> pairs that fall in the range of 0x14, 0x20 to 0x14, 0x2F in field 1,
> shall be replaced with 0x15, 0x20 to 0x15, 0x2F when used in field
> 2.
> 2. The non-printing character of the miscellaneous control-character
> pairs that fall in the range of 0x1C, 0x20 to 0x1C, 0x2F in field
> 1, shall be replaced with 0x1D, 0x20 to 0x1D, 0x2F when used in
> field 2.
This basically means that `cc1=0x15` in field 2 should be interpreted as
`cc1=0x14` in field 1, and same for `0x1D -> 0x1C`.
The `isMiscCode` method above already handles this by ignoring the LSB
(the only difference between `0x14` and `0x15`, and `0x1C` and `0x1D`)
by AND-ing with `0xF6` instead of `0xF7`. This change uses the same
trick in `isServiceSwitchCommand`.
Issue: google/ExoPlayer#10666
#minor-release
PiperOrigin-RevId: 483927506
(cherry picked from commit 7c6d492ff1)
Split inner interface into separate file, which will go in common
module. The old interface will be deprecated and extends the new.
#cleanup
PiperOrigin-RevId: 483732226
(cherry picked from commit ad52b68c73)
This is a no-op, but it's more 'correct' because it avoids any potential
sign mix-ups that come from storing an unsigned byte (with a
potentially set MSB) in a signed java byte variable.
PiperOrigin-RevId: 483409798
(cherry picked from commit 3d0f43a149)
Although it can be useful to check the output format, it's not required or needed.
For some AudioProcessor implementations, it is stated/obvious that
the output format will match the input, in which case there is no
a need to check the return value.
#cleanup
PiperOrigin-RevId: 483403679
(cherry picked from commit a7bfa12eec)
This listener will need to be passed to the MuxerWrapper to throw when
the Transformer is stuck.
PiperOrigin-RevId: 482433552
(cherry picked from commit e3f28421fd)
