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
In some DataSources, it is not easy to assign an error code at the throw site.
For example, CronetDataSource.readInternal() throws SocketTimeoutException
on L1033, and is caught at L754 as IOException and is thrown.
We need the logic to assign error code for the actual type of the error cause.
While we can certainly do in individual DataSources, IMO there's value in
making this logic generic at a higher level (like what is in this CL).
The catch and translation logic is borrowed from EPII:L646.
PiperOrigin-RevId: 385789629
Also rename hasPrevious/Next to hasPrevious/NextWindow for consistency.
This makes it clearer what the difference between
seekToPrevious/NextWindow and seekToPrevious/Next is.
PiperOrigin-RevId: 384643373
Applications may need to pass a non-visual context when creating
a DefaultTrackSelector (e.g., because they're audio-only or are
creating the selector in a background service).
Obtaining the default display via DisplayManager avoids the strict
mode violation that occurs when retrieving it via WindowManager.
#minor-release
PiperOrigin-RevId: 384487363
Most of the super-interfaces are deprecated, but the intention is that
only the types are deprecated and the methods themselves shouldn't be.
In order to reflect this in javadoc we override all the methods in
`Player.Listener` in order to 'cancel' the deprecation.
This change deliberately doesn't override methods that are explicitly
deprecated with documented replacements (like
`Player.EventListener#onPlayerStateChanged`) - these should contine to
be marked as deprecated in javadoc.
PiperOrigin-RevId: 384253725
The types (open/close/read) does not provide extra information about the thrown
playback exception, and they are not utilized at higher levels.
PiperOrigin-RevId: 384219870
