We already allow mixed mime type and mixed sample rate adaptation on request,
so for completeness, we can also allow mixed channel count adaptation.
Issue:#6257
PiperOrigin-RevId: 261930046
This also decouples EventMessageEncoder's serialization schema from the emesg spec (it happens to still match the emsg-v0 spec, but this is no longer required).
PiperOrigin-RevId: 261877918
If we keep streams in chunk sources after selecting new tracks, we also keep
a reference to a stale disabled TrackSelection object. Fix this by updating
the TrackSelection object when keeping the stream. The static part of the
selection (i.e. the subset of selected tracks) stays the same in all cases.
Issue:#6256
PiperOrigin-RevId: 261696082
If we keep streams in chunk sources after selecting new tracks, we also keep
a reference to a stale disabled TrackSelection object. Fix this by updating
the TrackSelection object when keeping the stream. The static part of the
selection (i.e. the subset of selected tracks) stays the same in all cases.
Issue:#6256
PiperOrigin-RevId: 261696082
We currently keep the sequence number if we don't reset the position. However,
the sequence number should be kept if we don't reset the state. Otherwise
re-prepare with position reset is counted as new playback although it's still
the same.
PiperOrigin-RevId: 261644924
- Test seeking to (timeUs=0, position=0), which should always work
and produce the same output as initially reading from the start
of the stream.
- Reset the input when testing seeking, to ensure IO errors are
simulated for this case.
PiperOrigin-RevId: 261317898
- When in STATE_SEEK with targetGranule==0, seeking would exit
without checking that the input was positioned at the correct
place.
- Seeking could fail due to trying to read beyond the end of the
stream.
- Seeking was not robust against IO errors during the skip phase
that occurs after the binary search has sufficiently converged.
PiperOrigin-RevId: 261317035
A previous change switched to calculation of the bitrate based on the
first MPEG audio header in the stream. This had the effect of fixing
seeking to be consistent with playing from the start for streams where
every frame has the same padding value, but broke streams where the
encoder (correctly) modifies the padding value to match the declared
bitrate in the header.
Issue: #6238
PiperOrigin-RevId: 261163904
- Test seeking to (timeUs=0, position=0), which should always work
and produce the same output as initially reading from the start
of the stream.
- Reset the input when testing seeking, to ensure IO errors are
simulated for this case.
PiperOrigin-RevId: 261317898
- When in STATE_SEEK with targetGranule==0, seeking would exit
without checking that the input was positioned at the correct
place.
- Seeking could fail due to trying to read beyond the end of the
stream.
- Seeking was not robust against IO errors during the skip phase
that occurs after the binary search has sufficiently converged.
PiperOrigin-RevId: 261317035
Two tests have very low propability flakiness (1:1000) due to not waiting for
a seek in one case and the chance of already being ended in another case.
Fix these and also adjust wrong comments about state changes.
PiperOrigin-RevId: 261309976
These values can easily default to the empty track group and the empty
selection. As a result we can remove restrictions about not calling
holder.getTrackGroups before the period finished preparation.
PiperOrigin-RevId: 261280927
Android considers ALAC initialization data to consider of the magic
cookie only, where-as FFmpeg requires a full atom. Standardize around
the Android definition, since it makes more sense (the magic cookie
being contained within an atom is container specific, where-as the
decoder shouldn't care what container the media stream is carried in)
Issue: #5938
PiperOrigin-RevId: 261124155
Checking inputPosition == 0 isn't sufficient because the synchronization
at the top of read() may advance the input (i.e. in the case where there's
some garbage prior to the seek frame).
PiperOrigin-RevId: 261086901
