Before this CL, SessionPlayerConnector getters had returned
UNKNOWN_TIME in idle state. It was because
SessionPlayerConnector had followed AndroidX media2
MediaPlayer's behavior, which was the baseline code of the
SessionPlayerConnector.
With this CL, SessionPlayerConnector getters directly return
underlying Player's value, rather than considering calls
in IDLE state as an exception and fallbacks to the default
UNKNOWN_TIME.
PiperOrigin-RevId: 327420940
ExoPlayer is now the trusted source of playlist and can be
used by other components without breaking
SessionPlayerConnector's cached playlist.
PiperOrigin-RevId: 327266929
Playlist can now be obtained directly from Timeline windows
in any state. So make ExoPlayer as the trusted source of
playlist, instead of SessionPlayerConnector.
PlayerWrapper still need to keep the list of media items.
It's used to detect whether the Timeline change is caused by
changes in media items or not, and only notify
SessionPlayer.PlayerCallback#onPlaylistChanged() only when
the playlist is really changed.
PiperOrigin-RevId: 327231820
MediaSession requires prepared Looper in 1.0.3-stable release,
which is the latest stable release for now.
The requirement would be removed in 1.1.0-stable, but workaround
is needed meanwhile.
PiperOrigin-RevId: 327220042
Find sbgp and sgpd boxes with grouping_type == seig in the case they don't
come first. Previoulsy we would only find them if they came first.
Issue: Issue: #7716
PiperOrigin-RevId: 325407819
The sniffer sniffs boxes at the start of the file to try and determine
whether the file is fragmented. However, if the file is extremely short
then it's possible that sniffing will try and read beyond the end of
the file, resulting i EOFException being thrown.
In general it's OK for sniffing to throw EOFException if the file is
not of the correct type. The problem in this case is that EOFException
can be thrown for an actual MP4 file, due to the sniffer continuing up
sniff atoms up to bytesToSearch in case the file is fragmented.
PiperOrigin-RevId: 325205389
Having both in the trun box is not allowed (see section section 8.8.8.1
of ISO/IEC 14496-12:2015) but this CL makes the code more robust in case
this happens. Before this change, the first sample flag was not read,
making subsequent reads incorrect.
Issue: #7698
PiperOrigin-RevId: 325212160
Float values are allowed to be > 0dbfs,
it is just not nominal as it will might
distort the signal when played without
attenuation.
This is also consistent with
[AudioTrack.write(FloatBuffer)](https://developer.android.com/reference/android/media/AudioTrack#write(float[],%20int,%20int,%20int)) that explicitly
allows it up to 3dbfs.
PiperOrigin-RevId: 321345077
