When a seek is performed, renderers currently perform the
actions that they need to take in two places: Some changes
are performed in seekTo implementations. Other changes are
performed when discontinuities are read from the source.
In HLS we need to perform what is effectively a seek
originating in the source. To support this, this CL allows
discontinuities read from the source to modify the playback
position. All actions that renderers perform as a result
of a seek are moved to be performed when a discontinuity is
received.
Best way to understand CL:
- Look at SampleSource interface change and then at the
concrete implementations, to make sure they've been
changed properly.
- Look at SampleSourceTrackRenderer change.
- Look at concrete renderers. The general pattern is that
code previously performed in seekTo and READ_DISCONTINUITY
is merged into onDiscontinuity().
Note: This will be further untangled in V2.
Issue #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112720746
Also apply the workaround for the secure variant of OMX.SEC.avc.dec.
Note that it's not necessary to do the same for the RK decoder in
the method below, since that workaround is targeted at SDK_INT<=17
and secure decoders only came along in 18.
Issue: #603
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112395376
Targeting to all API level 19 devices using the OMX.SEC.avc.dec
decoder is probably the right thing to do. It shouldn't have
negative implications if we apply the workaround on devices that
don't really need it, except to slow down seeking slightly due
to decoder re-allocation. Given we're talking about JB, I think
the priority should be to "make sure it works".
Issue: #951
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111514406
This allows implementation and injection of custom MediaCodecSelector
instances. By injecting a custom selector, it's possible for applications
to exert more control over which decoder(s) they instantiate. For example,
applications can force use of a software decoder.
GitHub Issue #938
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=110369810
* Add additional Widevine samples.
* Improve error messaging in demo app around decoders.
* Display toasts for playback errors related to missing insecure
decoders, missing secure decoders, decoder instantiation failure
and decoder query failure.
* Remove checks from SampleChooserActivity, since the above largely
covers off this problem.
- The old approach was technically incorrect, because the checks
were "capacity < sampleSize" and hence neglected the fact that
the buffer position may be greater than 0 (e.g. if the caller
wants to prefix the sample with some additional data).
- Also proactively throw an exception if the buffer is too small,
rather than wait for the failure when we actually do the write.
Remove MPEG TS stream filtering based on AudioCapabilities.
Pass AudioCapabilities to MediaCodecAudioTrackRenderer so it can choose between
passthrough/raw and decoding for AC-3 tracks.
- Generalize rendererEnabledFlags to be selected track indices through
ExoPlayerImpl/ExoPlayerImplInternal.
- Selecting an out-of-bound track index (e.g. -1) is equivalent to
disabling a renderer prior to the generalization.
- A prepared TrackRenderer that exposes 0 tracks is equivalent to a
TrackRenderer in the STATE_IGNORE state prior to the generalization.
Issue #514.
1. Workaround for decoders that fail to handle the END_OF_STREAM flag.
2. Revert processing of final output buffer if it's non-empty. This
introduced another bug (#596)
Reverts: b88012f51f
Issue: #417
Issue: #596
1. Remove requirement for TrackRenderer implementations to report
current position, unless they are time sources.
2. Expose whether renderers have media to play. The immediate benefit
of this is to solve the referenced GitHub issue, and also to only
display the appropriate Audio/Video/Text buttons in the demo app
for the media being played. This is also a natural step toward
multi-track support.
Github issue: #541
This makes it so that it's no longer necessary to specify the number
of downstream renderers to HlsSampleSource, FrameworkSampleSource and
ExtractorSampleSource, by forcing the downstream renderers to register
with the SampleSource instances in their constructors. This eliminates
a common source of subtle client bugs where the passed value is incorrect.
This also fixes a technical mistake where HlsChunkSource is fed
seekPositionUs=-1 when obtaining the first chunk. This is wrong,
but the usage of this variable within HlsChunkSource enforces that
the seek must stay within bounds, so we get away with it.
Issue: #385
The OMX component needs to be configured with a format that has a
MIME type of audio/raw. Remove Ac3PassthroughAudioTrackRenderer,
which is no longer used.
- Rather than returning a map, return a DrmInitData object,
with mapped and non-mapped implementations.
- Include a suitable mimeType to pass to the MediaDrm. Previously
we were incorrectly passing the mimeType of the samples,
where-as MediaDrm expects the container mimeType. Note that
it doesn't matter whether the mimeType starts with "video" or
"audio", hence using video mimeTypes everywhere.
It was possible for a codec input buffer to be filled with two frames' worth of
data, if seekTo was called after populating a buffer, if waitingForKeys was true
and seeking did not trigger a flush. This caused the CryptoInfo to be configured
as if the input buffer contained a large amount of reconfiguration data as
cleartext.
Move resetting waitingForKeys to flushCodec, so that we don't try to read the
next sample from the source until the first one has been consumed or discarded.
The complexity around not enabling the video renderer before it
has a valid surface is because MediaCodecTrackRenderer supports
a "discard" mode where it pulls through and discards samples
without a decoder. This mode means that if the demo app were to
enable the renderer before supplying the surface, the renderer
could discard the first few frames prior to getting the surface,
meaning video rendering wouldn't happen until the following sync
frame.
To get a handle on complexity, I think we're better off just removing
support for this mode, which nicely decouples how the demo app
handles surfaces v.s. how it handles enabling/disabling renderers.
* this fixes a bug when switching from HE-AAC 22050Hz to AAC 44100Hz (the AudioTrack was not reset and we were trying to send a bad number of bytes, triggering a "AudioTrack.write() called with invalid size" error)
* this also improves quality switches, making it almost seamless
