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)
