Tests in `SilenceSkippingAudioProcessorTest` used half as many short integers as needed for channel values when generating alternating silence/noise input. Fix this by passing left and right channel input.
PiperOrigin-RevId: 509188074
The AsynchronousMediaCodecAdapter's queuing thread stores any exceptions
raised by MediaCodec and re-throws them on the next call to
queueInputBuffer()/queueSecureInputBuffer(). However, if MediaCodec
raises and error while queueing, it goes into a failed state and does
not announce available input buffers. If there is no input available
input buffer, the MediaCodecRenderer will never call
queueInputBuffer()/queueSecureInputBuffer(), hence playback is stalled.
This change surfaces the queueing error through the adapter's dequeueing
methods.
PiperOrigin-RevId: 508637346
Previously, Robolectric's instrumentation updated all constructors to be
public. This caused two main types of problems:
1) When non-public constructors were made public and added to the Android API,
Robolectric allowed tests to incorrectly use the constructors on older SDK
levels (where they were non-public). This most commonly occurs for
AccessibiltyEvent and AccessibilityNodeInfo.
2) When reflection was used to instantiate classes that were instrumented by
Robolectric, all constructors were accessible.
Fix issues across Google3 Robolectric tests that were affected by this issue.
A forthcoming change will fix the instrumentation in Robolectric to prevent
this type of issue from occurring.
Tested:
TAP --sample ran all affected tests and none failed
http://test/OCL:507861075:BASE:507805409:1675803313108:f2128fa4
PiperOrigin-RevId: 508087822
If a renderer error happens while processing readahead data for the
next item in the playlist, we currently throw the error immediately
and only set the item id in the error details. This makes it harder
to associate the error to the right item. For example, the user
facing UI is likely not updated to show the failing item when the
error is reported.
This can be improved slighly by force setting the position to the
failing item. The playback still fails immediately, but this can't
be avoided because the renderer itself went into an error state.
PiperOrigin-RevId: 507808635
Can be used to combine multiple media items into a single timeline window.
Issue: androidx/media#247
Issue: google/ExoPlayer#4868
PiperOrigin-RevId: 506283307
MergingMediaPeriod creates its track groups with ids concatenating position in its periods array and the underlying child track group id. The ids can be used in selectTracks for matching to periods list.
Issue: google/ExoPlayer#10930
PiperOrigin-RevId: 505074653
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
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
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
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
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
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
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
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
Currently, repeating the same item (via seekNext/Previous) implicitly
results in a seek to the default position of the current item, which
looks exactly the same as a direct seek. As a result, we don't send
onMediaItemTransition as we would for every other seekNext/Previous
call.
This can be fixed by explicitly marking the repeat case in the internal
BasePlayer/ExoPlayerImpl methods, so that the callback can be triggered.
Issue: google/ExoPlayer#10667
PiperOrigin-RevId: 481951788
We already have logic to end all session except the current one if the
current one doesn't have a MediaPeriodId yet. This is assuming that this
only happens after a seek on the app side where the player doesn't have
detailled knowledge about the MediaPeriodIds yet.
Currently this logic isn't triggered if the window we are coming from
doesn't have its MediaPeriodId either as we run into another check that
keeps sessions around until we have a valid windowSequenceNumber.
Swapping both conditions fixes this case without breaking any of the
other known transition scenarios.
Issue: androidx/media#180
PiperOrigin-RevId: 480866465
If the sample type is Dolby Vision and the display does not support Dolby Vision, then the capabilities DecoderSupport flag is set to DECODER_SUPPORT_FALLBACK_MIMETYPE. This denotes that the renderer will use a decoder for a fallback mimetype if possible. This alters track selection as tracks with DecoderSupport DECODER_SUPPORT_PRIMARY are preferred.
UnitTests included
-DefaultTrackSelector test that checks track selection reordering with DECODER_SUPPORT_FALLBACK_MIMETYPE
-MediaCodecVideoRenderer test that checks setting of DecoderSupport flag based on Display's Dolby Vision support
Issue: google/ExoPlayer#8944
PiperOrigin-RevId: 480040876
* Add `setOutputStreamOffsetUs(long)` method in `AudioSink`.
* Add private methods `setOutputStreamOffsetUs(long)` method in `MediaCodecRenderer` and `DecoderAudioRenderer`.
* Add protected method `onOutputStreamOffsetUs(long)` method in `MediaCodecRenderer`, in which:
* `MediaCodecRenderer` itself will be no-op for this method.
* `MediaCodecAudioRenderer` will propagate this value to its `audioSink`.
* Add logics in `DecoderAudioRenderer` to calculate `outputStreamOffsetUs`.
PiperOrigin-RevId: 479265429
If the back buffer is using too much memory, there is a risk
playback could get stuck because LoadControl refuses to load
further data. This eventually results in a stuck-buffering
playback error.
We can detect this case, clear the back buffer and then ask
the LoadControl again to avoid failing playback in such a case.
PiperOrigin-RevId: 472679797
The stream offset is used to calculate the presentation time of
a metadata object when reading and later when playing, to calculate
the current presentation time to decide whether to send the metadata
to the output.
Accordingly, the presentation time of a pending metadata that has been
calculated with a given offset needs to be recalculated when the
stream offset changes.
#minor-release
PiperOrigin-RevId: 472499943
* Non-standard parameter comment; prefer `/* paramName= */ arg`
(see http://go/bugpattern/ParameterComment) (3 times)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content.
* File a bug under go/rosie-bug if there's an issue with how the CL was managed.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.
This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.
#codehealth
Tested:
Local presubmit tests passed.
PiperOrigin-RevId: 472254253
* Non-standard parameter comment; prefer `/* paramName= */ arg`
(see http://go/bugpattern/ParameterComment) (19 times)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content.
* File a bug under go/rosie-bug if there's an issue with how the CL was managed.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.
This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.
#codehealth
Tested:
Local presubmit tests passed.
PiperOrigin-RevId: 471022923
Increase the estimated max sample size for HEVC by 2x, and set a minimum
size of 2MB. The 2MB will be applied for resolutions up to 1080p, after
which the new calculation takes effect. This is in par with the
platform's HEVC software decoder.
PiperOrigin-RevId: 467641494
Some calls to handleBuffer return false while a previous
flush is still handled in the background.
Fix this by either asserting the method returns true if
we don't expect any delay, or calling it repeatedly until
it returns true (within a timeout).
PiperOrigin-RevId: 460474419
Previously two timelines that differed only in shuffle order were
considered equal, which resulted in no call to
Player.Listener.onTimelineChanged when calling
ExoPlayer.setShuffleOrder. This in turn resulted in no call to
MediaControllerCompat.Callback.onQueueChanged.
Also make a small fix inside ExoPlayerImpl.setShuffleOrder, to ensure
that the new shuffle order is used when constructing the masked
timeline.
Issue: google/ExoPlayer#9889
#minor-release
PiperOrigin-RevId: 457703727
NoUidTimeline still exists as a private detail of TestUtil, but it no
longer extends ForwardingTimeline because the interactions are quite
hard to reason about.
#minor-release
PiperOrigin-RevId: 457703593
Previously two timelines that differed only in shuffle order were
considered equal, which resulted in no call to
Player.Listener.onTimelineChanged when calling
ExoPlayer.setShuffleOrder. This in turn resulted in no call to
MediaControllerCompat.Callback.onQueueChanged.
Also make a small fix inside ExoPlayerImpl.setShuffleOrder, to ensure
that the new shuffle order is used when constructing the masked
timeline.
Issue: google/ExoPlayer#9889
#minor-release
PiperOrigin-RevId: 457703727
(cherry picked from commit 5c7ec13e85d32bdb464082069d462c740bc7cd55)
NoUidTimeline still exists as a private detail of TestUtil, but it no
longer extends ForwardingTimeline because the interactions are quite
hard to reason about.
#minor-release
PiperOrigin-RevId: 457703593
(cherry picked from commit 292f6de6305fa7fbbd2b80223e7860aa1f69118a)
1. The offloadSchedulingEnabled value doesn't need to be in
PlaybackInfo because it's never updated in EPII.
2. The sleepingForOffload value in EPII wasn't updated explicitly
(just via the return value of a method). It was also only
meant to be enabled while the player is actively playing, but
confusingly triggered from a path where the player may
theoretically be buffering as well.
3. The offload sleeping (=not scheduling doSomeWork) was interwoven
into the actual scheduling code making it slightly hard to follow.
This can be improved slightly by keeping the offload sleeping
decision and the scheduling separate.
PiperOrigin-RevId: 457427293
