Move the code in its own class as DefaultAudioTrack
is getting very big. It also help for testability.
The new class is easily configurable and highly tested.
Manual test was used to catch any regression.
https://github.com/google/ExoPlayer/issues/8891
PiperOrigin-RevId: 424602011
AnalyticsCollector can't be null when passed into ExoPlayerImplInternal,
so there is no need to pass it around as nullable.
PiperOrigin-RevId: 424594031
Two of the sessions are finished at the same time in the test
and the order of the corresponding callbacks depends on the randomly
generated session string and the order these strings are stored in a
HashSet.
Update test to assert both callbacks are called and they contain the
right arguments, but don't assert on the order of these two callbacks.
PiperOrigin-RevId: 424548819
Ad playback shouldn't be affected by manual speed adjustments set
by the user. This change enforces unit speed for ad playback.
Issue: google/ExoPlayer#9018
PiperOrigin-RevId: 424546258
This only affects playbacks using the
experimentalUseProgressiveMediaSourceForSubtitles method.
Also update the SingleSampleMediaSource instantiation to be more
similar, to try and highlight differences like this in future.
PiperOrigin-RevId: 424545980
In some cases we need to update the PlaybackParameters at period
boundaries, for example when switching from live to VOD and live
playback speed adjustment was still active at the point of switching.
Currently, we send the update when the playing MediaPeriod changes in
EPII, which is slightly too late because the new speed gets only applied
after the entire existing AudioTrack buffer has been played out.
We can time the update slightly better by updating the values at the
point where we change the reading period. This makes the update slightly
too early because it also applies to all samples currently in the
decoder. But generally, this is a lot better because the time spent
in the decoder is likely to be considerably lower than the duration of
the AudioTrack buffer.
Note that this change isn't perfectly aligning to the period boundary,
but reduces the number of samples with the wrong speed to a minimum.
If we are getting around to add additional code that allows updating
the speed at exactly the boundary, it also needs to be triggered from
the reading period update, so the new code location is also helpful in
the future.
Issue: google/ExoPlayer#9018
PiperOrigin-RevId: 424540551
When I locally link to exoplayer source modules as described in the README and I
do this directly into a fig/citc client, I get an error saying
"missing_aar_type_workaround.gradle': 79: unexpected token: || @ line 79, column
29.". I can fix this by wrapping the expression in parenthesis (¯\_(ツ)_/¯).
I don't think this file lands in the public source tree, but if we want to
correct this, it may help someone from the team.
This CL can be ignored and reverted also.
PiperOrigin-RevId: 424537619
* @CryptoType is a TYPE_USE annotation, so should appear after modifiers and directly before the type.
(see go/java-style#s4.8.5-annotations)
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 the change looks generally problematic.
* 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: 423821355
Issue: google/ExoPlayer#9775
We got a few issues for this on GH already. Some RTSP servers do not provide
track timing in PLAY responses, or the timings are invalid.
Missing timing means the RTSP stream is not seekable. Added method to
1. Update the timeline that seek is not possible
2. Report read discontinuity so that playback can start from the beginning.
PiperOrigin-RevId: 423281439
If the output sample MIME type is inferred from the input
but is not supported by the muxer, we fallback to transcoding
to a supported sample MIME type.
The audio and video renderers need to make sure not to select the PassthroughSamplePipeline for this case. Which sample MIME type
to choose is decided by the EncoderFactory.
PiperOrigin-RevId: 423272812
To avoid the `MediaPeriodQueue`to discard the reading period, we can set the next ad of an ad group early and then (possibly) only change it's duration once we receive the actual duration. This way we avoid a rebuffering as a result of the reading period being discarded.
The change also takes care to properly set ad break and their durations when we join the live stream at the moment when an ad is playing.
PiperOrigin-RevId: 423163467
* @CryptoType is a TYPE_USE annotation, so should appear after modifiers and directly before the type.
(see go/java-style#s4.8.5-annotations)
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 the change looks generally problematic.
* 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: 423821355
We currently only end sessions on Timeline updates if the associated media
is no longer in the playlist. But we should also end all sessions that are
finished as a result of the timeline update (similar to how this is done for
discontinuities). This issue was introduced by 394ab7bcfd
PiperOrigin-RevId: 423075855
Issue: google/ExoPlayer#9775
We got a few issues for this on GH already. Some RTSP servers do not provide
track timing in PLAY responses, or the timings are invalid.
Missing timing means the RTSP stream is not seekable. Added method to
1. Update the timeline that seek is not possible
2. Report read discontinuity so that playback can start from the beginning.
PiperOrigin-RevId: 423281439
If the output sample MIME type is inferred from the input
but is not supported by the muxer, we fallback to transcoding
to a supported sample MIME type.
The audio and video renderers need to make sure not to select the PassthroughSamplePipeline for this case. Which sample MIME type
to choose is decided by the EncoderFactory.
PiperOrigin-RevId: 423272812
We currently don't check which session is causing a network transfer
(it could be a preloaded item in a playlist). To clearly associate
network transfer data with sessions, we need to keep track of
transferred bytes and transfer time per session.
PiperOrigin-RevId: 422867845
To avoid the `MediaPeriodQueue`to discard the reading period, we can set the next ad of an ad group early and then (possibly) only change it's duration once we receive the actual duration. This way we avoid a rebuffering as a result of the reading period being discarded.
The change also takes care to properly set ad break and their durations when we join the live stream at the moment when an ad is playing.
PiperOrigin-RevId: 423163467
We currently only end sessions on Timeline updates if the associated media
is no longer in the playlist. But we should also end all sessions that are
finished as a result of the timeline update (similar to how this is done for
discontinuities). This issue was introduced by 394ab7bcfd
PiperOrigin-RevId: 423075855
We currently don't check which session is causing a network transfer
(it could be a preloaded item in a playlist). To clearly associate
network transfer data with sessions, we need to keep track of
transferred bytes and transfer time per session.
PiperOrigin-RevId: 422867845
We may fall back to a different sample MIME type because
a) the sample MIME type inferred from the input is not supported
by the muxer or b) no encoders are available for the the requested
sample MIME type.
PiperOrigin-RevId: 422849036
