This CL contains integration of the ExoplayerCuesDecoder and the
SubtitleExtractor with the player. The SubtitleExtractor is integrated
inside the DefaultMediaSourceFactory. The flag was added to the
state of the DefaultMediaSourceFactory to let user decide between the
ProgressiveMediaSource and the SingleSampleMediaSource as a source for
subtitles. Choosing the ProgressiveMediaSource will cause data to flow
through the SubtitleExtractor and eventually the ExoplayerCuesDecoder.
PiperOrigin-RevId: 394500305
Empty buffer with flag C.BUFFER_FLAG_END_OF_STREAM is send at the end
of the stream. Handling that flag properly is necessary to make the
ExoplayerCuesDecoder work properly with components like TextRenderer.
PiperOrigin-RevId: 394472642
In the old version, the transcoder uses decoder.isEnded() alone as the criteria
to stop the encoding/muxing process. It's rectified to:
- On decoder ending, signal the encoder of EOS after writing all decoded frames to it.
- On encoder ending, write end track to muxer.
PiperOrigin-RevId: 393322114
Make this behaviour optional, so it can be disabled for
AnalyticsCollectorTest where we don't use
FakeExoMediaDrm.LicenseServer.
PiperOrigin-RevId: 393133721
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
- Android 12 will not allow our download service to be
restarted from the background when conditions that
allow downloads to continue are met. As an interim
(and possibly permanent) solution, we'll keep the
service in the foreground if there are unfinished
downloads that would continue if conditions were met.
- Keeping the service in the foreground requires a
foreground notification. Hence we need to be able to
generate a meaningful notification for this state.
PiperOrigin-RevId: 391969986
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
The prototype is built upon Transformer and took many references from
TransformerAudioRenderer.
Please take a look and we can discuss more details.
PiperOrigin-RevId: 390192487
The result is plumbed back to `MediaCodecRenderer` via a new
`DrmSession#requiresSecureDecoder` method.
This allows us to use the `MediaDrm#requiresSecureDecoder` method added
in Android 12:
https://developer.android.com/reference/android/media/MediaDrm#requiresSecureDecoder(java.lang.String)
This change also removes
`FrameworkMediaCrypto#forceAllowInsecureDecoderComponents`, replacing it
with equivalent logic in `FrameworkMediaDrm#requiresSecureDecoder`.
PiperOrigin-RevId: 389616038
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
