This cl doesn't implement completely the API for
`ExoPlayerImpl` as
`onTrackSelectionParametersChanged` is not called.
The follow up cl adds `TrackSelectionParameters` in PlaybackInfo
to correctly propagate the change event and mask it.
Additionally `TrackSelectionParameters` is serialized as a Parcelable
for now. It is transitioned to bundleable in a follow up cl.
PiperOrigin-RevId: 392899918
StyledPlayerControlView was checking whether the player is an ExoPlayer
instance to set the track selector. This means that, if apps were
wrapping an ExoPlayer in a ForwardingPlayer (to replace a
ControlDispatcher for example), the track selector wasn't set anymore.
#minor-release
PiperOrigin-RevId: 391776305
Samples are serialized using our custom CueEncoder. Information in
which format samples are encoded is needed by Renderer to decide which
decoder to use. Extractor receives Format object in the constructor and
prepares new Format object with sampleMimeType moved to codecs field
and new sampleMimeType set to "custom serialized exoplayer Cue".
PiperOrigin-RevId: 391739866
Most of those objects needs to be sent to MediaControler.
`TrackSelectior.Parameters` could have stayed Parcelable,
but it needs to be `Bundleable` as it inherit from
`TrackSelectionParameters` that is and needs to be
serializable anyway for the demo app.
As a result it has also been migrated to bundleable.
PiperOrigin-RevId: 391353293
Adding a CHANGE_FRAME_RATE_STRATEGY_ALWAYS strategy is
omitted from this commit, since adding it is more complicated
than just plumbing it through and leaving everything else
unchanged. Specifically, VideoFrameReleaseTimeHelper would
need updating to behave differently when such a strategy is
enabled. It currently calls setFrameRate in cases such as
pausing, seeking and re-buffering, on the assumption that
changes to the underlying display refresh rate will only be
made if they can be done seamlessly. For a mode in which
this will not be the case, it makes more sense to stick to
the content frame-rate when these events occur. It may also
make sense to only use explicit content frame-rate values,
and not those inferred from individual frame timestamps.
Finally, for adaptive content containing a mix of frame-rates,
it makes sense to use the maximal frame-rate across all
variants, and to avoid calling setFrameRate on switches from
one variant to another.
Applications that know the frame-rate of their content can
set ExoPlayer's strategy to CHANGE_FRAME_RATE_STRATEGY_OFF and
then use setFrameRate directly on the output surface. Note that
this is likely to be a better option for apps than anything we
could implement in ExoPlayer, because the application layer
most likely knows the frame-rate of the content earlier than
ExoPlayer does (e.g., to perform the disruptive mode switch
at the same time as an activity transition).
Adding CHANGE_FRAME_RATE_STRATEGY_ALWAYS will be deferred
until there's clear demand for it. In the meantime, we'll
recommend the alternative approach above.
PiperOrigin-RevId: 389610965
This CL moves SubtitleDecoder and all its dependencies
to common in order to enable using it in extractor
module while implementing SubtitleExtractor.
PiperOrigin-RevId: 388979021
This CL introduces two classes:
* CueEncoder - encodes list of Cue object into byte array.
* CueDecoder - decodes byte array into list of Cue objects.
This two classes are necessary in order to push Cues through SampleQueue. This classes are meant to be used by subtitle Extractor.
PiperOrigin-RevId: 388932088
These API levels have both been finalized. We're also calling methods
from these API levels directly, which may not exist if a device is
running a non-finalized R or S release.
PiperOrigin-RevId: 388903410
This change removes ERROR_CODE_IO_NETWORK_UNAVAILABLE,
ERROR_CODE_IO_NETWORK_CONNECTION_CLOSED, and ERROR_CODE_IO_DNS_FAILED
in favor of keeping only ERROR_CODE_IO_NETWORK_CONNECTION_FAILED.
PiperOrigin-RevId: 388715972
The AnalyticsCollector releases listeners lazily so that listener
callbacks triggered on the application looper after
SimpleExoPlayer.release() are still handled. The change in ListenerSet
to post the onEvents callback on the front of the application looper
changed (correctly) how onEvents are propagated, however this made
the AnalyticsCollector deliver onEvents with out-of-order EventTimes.
This change fixes AnalyticsCollector to trigger onPlayerReleased() and
the matching onEvents() event in the correct order.
#minor-release
PiperOrigin-RevId: 388668739
- Use timestampOffsetUs == C.TIME_UNSET directly as the way of
determining whether the adjuster has determined the offset,
rather than relying on lastSampleTimestampUs checks for this.
- Remove comment referring to lastSampleTimestampUs as holding
the "adjusted PTS". Its value may not have originated from a PTS
timestamp. It's also confusing to refer to it as "adjusted"
given timestampOffsetUs has not been applied to it.
- Fix PassthroughSectionPayloadReader to make sure it'll never
output a sample with an unset timestamp.
#minor-release
PiperOrigin-RevId: 388226180
Prior to this change, an initalized TimestampAdjuster that's then
reset with DO_NOT_OFFSET would incorrectly continue to apply the
offset.
Also add a test case for this issue, and for some other simple use
cases.
#minor-release
PiperOrigin-RevId: 388182645
DefaultHttpDataSource and OkHttpDataSource can share the same error code
assigning logic.
Fixes CronetDataSource's handling of closed connection.
PiperOrigin-RevId: 387791679
The dokka javadoc generation tool complains when parameter names don't match between a method and its override. This change updates occurrences where there is currently a mismatch.
PiperOrigin-RevId: 387367509
The dokka javadoc generation tool complains when parameter names don't match between a method and its override. This change updates occurrences where there is currently a mismatch.
Notable renamings that might be controversial:
- `onPlaybackStateChanged(int state)` to `onPlaybackStateChanged(int playbackState)` affected a lot of lines but seems more consistent with other '-Changed' methods.
- `handleMessage(int messageType, Object payload)` to `handleMessage(int messageType, Object message)`
- `ExtractorInput` and `DataSource` inherit `DataReader` which had `read(byte[] target, ...`, while data sources normally called the first parameter `buffer`. I have standardized these all to use `buffer` even though it looks out of place in the `ExtractorInput` interface (which has more `read` methods with `target`).
PiperOrigin-RevId: 387290360
The documentation on ByteArrayOutputStream and GZIPOutputStream isn't
completely clear that an IOException will *never* happen, so
AssertionError seems a bit strong - but it seems very unlikely, so we
just use IllegalStateException instead.
#minor-release
PiperOrigin-RevId: 387169297
The inference is used when nesting DataSourceExceptions. It is removed because
nesting does not add additional value in surfacing the exceptions, and it is
better to assign an error code at the throw site (in the "leaf" or the bottom
most data source).
PiperOrigin-RevId: 386919118
