This is the first CL in a series to add chunkless preparation support.
Also did a bit a tidying up in HlsSampleStreamWrappen and
HlsMasterPlaylistParserTest.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174461737
This also allows exposing multiple CC channels to any fMP4 extractor client.
Issue:#1661
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174458725
First fix, prevents forced rewriting when cipher is set but encrypt is
false.
Second, removes the store() call in SimpleCache.initialize() so
initialization doesn't fail because of CachedContentIndex write issues.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174450586
The mediaChunks.size() > 1 check was supposed to ensure this, and
did roughly the right thing when there was only a single stream
(although it was unnecessarily restrictive in preventing chunk
cancelation for the first chunk, where bytesLoaded != 0 and none
of the samples had been consumed).
Now we have multiple streams the check doesn't do the right thing,
and adding a back-buffer feature will make even more incorrect.
This change switches to checking the condition we actually want
to check directly :).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174449398
*** Reason for rollback ***
Breaks setting PlaybackParameters before start of playback
*** Original change description ***
Add support for float output in DefaultAudioSink
Also switch from using MIME types to C.ENCODING_* encodings in DefaultAudioSink.
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174445506
Client can add this functionality by extending DownloadService.
Also made DownloadManager accept multiple listeners. So instead of
broadcast event, client can listen to DownloadManager directly.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174335820
Instead of using an Executor to run DownloadTasks creates and manages
threads internally.
Also added DownloadThread internal class to better separate the code
that doesn't run on the main thread.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174036872
1. Move Timeline/Manifest into PlaybackInfo
2. Don't update externally visible Timeline/Manifest during preparation
3. Ignore MSG_POSITION_DISCONTINUITY during preparation
4. Correctly set masking variables at start of preparation, and use them
Once this change goes in, PlaybackInfo will contain timeline, manifest
and position, which should always be self-consistent with one another.
The next step would then be to move a bunch of logic in ExoPlayerImpl
that derives state from timeline and position into PlaybackInfo, and
split that into its own top level class that can be easily tested to make
sure it never IndexOutOfBounds.
I think we could also replace the masking variables and instead just assign
a new PlaybackInfo to the playbackInfo variable whenever we're doing
something that requires masking. This should be possible because we no
longer update playbackInfo whenever we have pending acks. It would
require allowing PlaybackInfo to mask the window position internally when
the timeline is empty, but I think this is ok, and again is something we
could test pretty easily.
Issue: #3362
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173909791
This makes it a bit more obvious what's going on during
preparation. In particular, it makes it clear that
MSG_SOURCE_INFO_REFRESHED arrives before MSG_TRACKS_CHANGED.
Issue: #3362
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173392080
Also switch from using MIME types to C.ENCODING_* encodings in DefaultAudioSink.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173379623
We don't expect this case to occur, since track selection is
normally expected to check canAcquireSession before selecting
a track. Nevertheless, if an attempt is made to acquire a
session when the media doesn't support the manager's UUID, we
should fail in a more graceful way.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173124170
Other catch blocks in this class catch everything. This one should
too.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173118891
Tasks conflict if both of them work on the same media and at least one
of them is remove action.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172741795
We have been using USE_CHORD_PITCH == false for a while and the quality of
pitch changes seems fine. It's now possible to set the sample rate too, but
this only works if USE_CHORD_PITCH is false, so remove the constant.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172736631
- When transitioning to a new period, the value of bufferedDurationUs
passed to TrackSelection.updateSelectedTrack was incorrectly set to
0. It should have been set to correctly reflect buffered media in
previous periods still being played out.
- This change fixes the issue described above, and also propagates the
playback position through to this method. The position of the next
load within the period can be calculated by adding the position and
bufferedDurationUs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172736101
If connecting a Bluetooth audio device fails, the AudioTrack may be left in a
bad state, where it is not actually playing and its position has jumped back to
zero. Detect and work around this case by resetting the track.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172600912
prepare and selectTracks receive the position from which any
loading should start, where-as continueLoading receives the
actual playback position. These are different in the case that
a previous period is still being played out.
Also removed "relative to the start of the period" from prepare
documentation because it couldn't really be relative to anything
else.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172592769
newPlayingPeriodHolder could be set then updated if seeking to a repeated period
that was loaded more than once. This led to MediaPeriodHolders leaking.
Only set newPlayingPeriodHolder once so that any later holders with the same
period identifier get released.
Also add a regression test. FakeMediaSource checks that all created
MediaPeriods were released when it is released.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172591937
This is not really useful with the DefaultAudioSink, but could be used in a
custom AudioSink when mixing audio from sources that have different sample
rates.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172434482
1. Ignore edit list where the sequence doesn't contain a sync
sample, rather than failing.
2. Make Mp4Extractor.readAtomPayload so it doesn't try and read
the same payload twice if a failure occurs parsing it.
3. Make processAtomEnded so that it doesn't pop the moov if
parsing it fails.
Issue: #3351
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172106244
This change fixes various issues:
- MobileHarness sometimes allocated devices with SDK < 16. As we have no tests running
on these SDKs, a new dimension filter for the mobile_test target ensures that only
devices with SDK >= 16 are selected. A similar filter for SDK version is also added
to the ABR playback tests to ensure no old devices are selected.
- DRM specific tests are skipped for Api < 18, but were not able to run because the
DashTestRunner class tried to link to the MediaDrm constructor. Moved the
constructor to a seperate Builder class to allow execution on Api levels 16 and 17.
- DashWidevineOfflineTest also tried to access code for Api >= 18 without checking
the current level.
- Action implementations which are waiting for events did not ensure that they have a
nextAction to wait for. This caused NullPointerExceptions when this next action was
scheduled.
- DefaultDrmSession always restored the offline keys when a new license was requested,
even if the keys were already restored. These repeated slow calls to restoreKeys
resulted in high numbers of dropped buffers.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171974859
Update the audio track selection logic in DefaultTrackSelector:
- When forcing lowest bitrate, use bitrate as tie-breaker when track scores are
the same, prefer the lower bitrate.
- Otherwise, use one of the following values as tie-breaker in order:
- ChannelCount
- SampleRate
- BitRate
If the format being checked is within renderer's capabilities, select it if it
has higher tie-break value, else, select it if it has lower tie-break value.
If all tie-break values are the same, prefer the already selected track.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171803092
MediaCodecRenderer implementations require DrmSessionManager<FrameworkMediaCrypto>,
but it's currently not possible for an app to provide a custom implementation due
to FrameworkMediaCrypto having a package private constructor. This change exposes
public FrameworkMediaCrypto constructors, hence removing this restriction.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171718853
Calling HandlerThread.quit() or .quitSafely() doesn't immediately terminate
the thread. It just instructs the Looper not to accept any new messages and
to terminate at the next opportunity. Added a HandlerThread.join() everywhere
where the intention is to close and release all resources and to stop all
threads.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171525241
This change also replaces individual DownloadAction versions with a
single master version.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171273880
For initial DRM provisioning and key request, we allow the requests to be
retried (with increasing delay for each successive retry) before failing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171271384
Controls are still hidden while playing ads, but if the app pauses the player,
controls will be shown. During ads, the player is not seekable.
When the player enters the background then returns to the foreground, the
content period may not be prepared, so also cache the content window duration.
This means that if the app reenters the foreground while an ad is paused the
time bar can be populated.
Issue: #3303
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171123428
Now this counter includes input buffers too, which are dropped as part of
skipping to keyframes for catch up.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171119930
If the current output buffer is very late and the playback position is in a
later group of pictures, drop all buffers to the keyframe preceding the
playback position.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170975259
This is useful to determine when a seek request was processed by the player
and all playback state changes (mostly to BUFFERING) have been performed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170826793
Updates DefaultDrmSessionManager to use the prefered Widevine version (v1
on >= 23 and v0 for < 23).
For other DRM schemes, uses the first scheme found.
* Always assume a renderer is ready if it's read to the end of
its current stream and there's a subsequent period already
prepared. This prevents getting stuck when a non-clock renderer
has a short stream.
* Switch to the standalone clock if the renderer providing the
media clock has read to the end of its current stream, is no
longer ready, and there's a subsequent period already prepared.
This prevents getting stuck when a clock renderer has a short
stream.
* Remove unnecessary clock synchronization logic (since it would
need to be made more complicated as a result of this change).
* Don't update the playing period holder when playWhenReady is
false. This avoids the position jumping to the start of the
next period when seeking to the very end of the current period
whilst paused (we still end up showing the first frame of video
from the next period, but fixing that will have to wait).
Github: #1874
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170717481
This avoids spurious position reports following an underrun.
Github: #1874
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170344399
This change allows applications to provide custom AudioSinks, which could be
based on android.media.AudioTrack like AudioTrackAudioSink, or could be
completely custom.
The refactoring is mostly mechanical and shouldn't result in any functionality
changes.
Some android.media.AudioTrack-specific details have to appear in the AudioSink
interface so this change modifies the javadoc on the AudioTrack (now AudioSink)
to note that some methods will have no effect.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170311083
This allows simplified listener implementations as most listeners
will not listen to all possible notifications.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170177821
This includes both cbcs and cenc. Will only work for streams that require a single
pssh.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169382884
There's no reason to perform the discontinuity check or skip
the adaptation field if we don't have a payload reader for
the packet.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169374609
This fixes infinite loop in LeastRecentlyUsedCacheEvictor.evictCache when index store fails.
Also made CachedContentIndex not final so it can be mocked and added a package protected SimpleCache
constructor so mock index can be injected.
Issue: #3260
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169249517
This case may happen if the max span size is more than the max size the
evictor is configured.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169101093
1- Avoid dropped buffers by using a PriorityQueue instead of a set.
2- Process the end of stream after non-EOS buffers.
Issue:#3250
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169077365
1. Only tell sessions that want provisioning when provisioning occurs.
2. Also propagate failure to provision to these sessions.
3. If a session responsible for provisioning is released, start
provisioning using another session instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168713918
- MediaDrmEventListener.onEvent is typically called on the
app's main thread. mediaDrmHandler is instantiated on the
playback thread. Hence mediaDrmHandler should be volatile
to ensure visibility.
- Nulling mediaDrmHandler could result in a NPE in onEvent.
Instantiate mediaDrmHandler (and don't null it again) to
avoid this. MediaDrmHandler.handleMessage will correctly
discard any events for sessions that are now closed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168707938
AdsMediaSource lives in the core library so only ImaAdsLoader remains in
the ima extension. AdsMediaSource takes an AdsLoader implementation.
ImaAdsMediaSource is deprecated rather than removed for now.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168707921
Currently, to make transition to next media period seamless, after the renderer
has read until the end of the current SampleStream, we may send it the next
SampleStream so the renderer may read from the next SampleStream ahead of the
transition.
For NoSampleRenderer, we should avoid doing this: skipping ahead for such
renderer doesn't have any benefit (the renderer does not consume data from
SampleStream), and it will change the provided rendererOffsetUs while the
renderer is still rendering from the playing media period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168669800
This allows listeners to easily determine the source of the discontinuity.
Reasons can be period transitions, seeks, and internal reasons.
Listeners still using the deprecated ExoPlayer.EventListener interface were
updated to Player.EventListener.
GitHub: #3252
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168549612
Remove gapless functionality that relies on MediaCodec, and implement this in
an AudioProcessor instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168547487
Currently our Renderer is always associated with and consume data from
some SampleStreams, which were constructed from the provided MediaSource.
There are use-cases, in which the users want to have simple Renderer
implementation that does not consume data from SampleStream at all, but
render using their custom logic at each rendering position - they mostly just
need ExoPlayer to keep track of the playback position and enable/disable the
renderer.
This CL adds support for such Renderer by adding a TRACK_TYPE_NONE.
Renderer of such type will be:
- Associated with null TrackSelection as the result of track-selection
operation.
- Associated with EmptySampleStream.
GitHub: #3212
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168545749
In live streaming, if the playback position is very close to live edge,
the buffered duration will never reach minDurationForQualityIncreaseMs,
which prevents switching from ever happening. So we will provide the
durationToLiveEdgeUs to AdaptiveTrackSelection in live streaming case,
so it can handle this edge case.
GitHub: #3017
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168535969
The release callback handler in Loader might not be alive
anymore. Catch this case to prevent warnings about sending
messages on dead threads.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167996538
Remaining instrumentation tests either use android.os.Handler or rely on assets.
In the latter case, the tests are difficult to migrate due to differences
between the internal and external build systems, and configuration needed in
Android Studio. In addition, SimpleCacheSpanTest remains as an instrumentation
test because it fails due to a problem with string encoding on the internal
build (and two other tests in its package are kept with it because they depend
on it).
This test removes a dependency from testutils on Mockito, as a different
version of Mockito needs to be used for instrumentation tests vs Robolectric
tests, yet both sets of tests need to rely on testutils. Mockito setup is now
done directly in the tests that need it.
Move OggTestData to testutils so it can be used from both instrumentation and
Robolectric tests.
It may be possible to simplify assertions further using Truth but this is left
for possible later changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167831435
Everything should go through the ExoMediaDrm layer. We still
need to abstract away the android.media exception classes, but
this is left as future work.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167710213
Reporting incorrect positions for ad playbacks was causing IMA to
think the ad wasn't playing, when in fact it was.
Issue: #3180
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167702032
Also pass an unresolved end point to ClippingMediaPeriod. This removes some
assertions checking timestamps in the ClippingMediaPeriod, but makes it
possible to identify when the end point is at the end of the media.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167683358
The default implementation is just calling through to handler.postDelayed,
while the fake clock uses its internal time value to trigger the handler
calls at the correct time.
This is useful to apply a fake clock in situations where a handler is used to
post delayed messages.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167567914
Currently FlacDecoder/FlacExtractor always perform resampling to 16bit. In some
case (with 24bit audio), this might lower the audio quality if the system
supports 24bit audio.
Since AudioTrack implementation supports resampling, we will remove the
resampling step, and return an output with the same bits-per-sample as the original stream.
User can choose to re-sample to 16bit in AudioTrack if necessary.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167494350
The bytesRemaining didn't always take into account any skipped bytes, which
meant that reaching the end of the file was not correctly detected in read().
Issue: #3216
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167016672
UTF-8 is the default charset on Android so this should be a no-op change, but
makes the code portable (in case it runs on another platform).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167011583
*** Reason for rollback ***
Doesn't work because trackOutputProvider can be null when extracting init data.
*** Original change description ***
Don't copy primary-track format to non-primary tracks
Copying non-primary-track formats to non-primary tracks
looks non-trivial (I tried; went down a dead-end), so
leaving that for now.
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166883654
1. Make LeanbackPlayerAdapter use a ControlDispatcher. This
allows apps to suppress control events in some circumstances,
and is in-line with our mobile controls.
2. Misc simplifications and cleanup to LeanbackPlayerAdapter.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166852816
Also workaround the non-repeatable queue and fix other minor issues.
Issue:#2283
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166848894
This mapping when we call into platform components also needs
to be applied when creating the MediaCrypto instance. The fix
is to stop propagating the UUID through all the createMediaCrypto
methods. This is unnecessary, since the eventual target already
knows its own UUID!
Issue: #3138
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166843372
Copying non-primary-track formats to non-primary tracks
looks non-trivial (I tried; went down a dead-end), so
leaving that for now.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166843123
Both cases were not supported so far. Added tests which all failed in the
previous code version and adapted the concatenated media sources to cope with
empty timelines and empty concatenations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166480344
This is mostly connecting the already stored shuffleMode with the timeline queries
for the playback order.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166199330
The media source is initialized with a DefaultShuffleOrder which can be changed at
any time. Whenever the list of media source is changed, the shuffle order is adapted
accordingly (either on the app thread if the player is not prepared yet, or on the
player thread). The shuffle order is then used to construct the timeline.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166198488
The media source is initialized with a DefaultShuffleOrder which can be changed at
any time. This shuffle order is then used within the corresponding timeline.
The isRepeatOneAtomic flag is extended to also suppress shuffling (now called
isAtomic only).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166197184
Make getMediaFormat protected so that subclasses can set additional MediaFormat
keys. For example, if the decoder output needs to be read back via an
ImageReader as YUV data it is necessary to set KEY_COLOR_FORMAT to
COLOR_FormatYUV420Flexible.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166195211
The implementation in the abstract base class takes care to forward the queries
to the correct methods given the shuffle mode and a given shuffle order.
All concatenated timeline implementations use an unshuffled order so far. The
handling of the shuffle orders will follow in other changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166191165
In addition, let unit test assert window indices for both shuffle modes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166191069
This functionality is most likely needed by UI modules which currently need
to obtain the timeline, the current repeat and shuffle modes and are only then
able to query the next/previous window index using this information.
Adding these methods simplifies these cumbersome requests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166181202
This allows to test the expected behaviour of timeline with different shuffle modes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166181091
This parameter is used by methods such as getNextWindowIndex
and getPreviousWindowIndex to determine the playback order.
Additionally, there are method to query the first and last
window index given the shuffle mode.
None of the timeline implementations nor the ExoPlayer
implementation supports shuffling so far.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166170229
The shuffle mode is saved using a message on the playback thread.
After setting the shuffle mode, the same media period holder verification
as for repeat mode changes gets executed.
Note: the shuffle mode is not used yet to change the playback order.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166060231
And implement a basic version of the methods in all implementations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166041342
These methods are only used in one place, and offer duplicate
functionality to checking getNext(Previous)WindowIndex == C.INDEX_UNSET.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165910258
There will be non-ExoPlayer players that can output text
and metadata, so the outputs should be standalone. There
may also be ExoPlayer instances that use non-standard
text and metadata renderers, for which this change also
makes sense.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165628420
If the main thread was interrupted during
ExoPlayerImplInternal.blockingSendMessage/release, the interrupted flag was
immediately set but then wait() was called on the next iteration. wait() would
immediately throw InterruptedException, causing the main thread to spin until
the blocking operation completed.
Instead of resetting the flag immediately, reset it after the blocking
operation completes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165426493
to be disabled gracefully: encrypted index files may be read, but plaintext will be written.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165196508
- HlsDownloader.loadManifest (previously called getHlsPlaylist)
suppressed errors for the offline case, where-as the DashUtil
equivalent method did not. This change makes them consistent
and moves both other to use ParsingLoadable.
- Enable GZIP for manifest loads in both cases.
- Use Uri rather than String to represent Uris. Previously the
strings were parsed into Uris quite deep in the code, which
isn't ideal if the parsing fails; you'd probably prefer the
error to occur early at the top level.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165181398
We've seen more than one issue filed where a developer has
registered a video listener and been confused by the fact
their SimpleExoPlayerView no longer works properly. There
are also valid use cases for having multiple metadata/text
outputs.
Issue: #2933
Issue: #2800
Issue: #2286
Issue: #2240
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164839882
- There is a proper ClearKey UUID now. This change requires
it to be used instead of the Common PSSH UUID when instantiating
DRM components.
- Internally, we'll map the ClearKey UUID onto the Common PSSH
UUID where necessary to (a) access the ClearKey CDM on older
devices, and (b) access drm init data stored under the Common
PSSH UUID in the stream.
Issue: #3138
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164839213
It's needed in multiple places. MediaSessionConnector uses it
today. Our leanback connector will also use it. Maybe
SimpleExoPlayerView should use one too, to show the message to
the user when an error occurs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164720020
I considered using Util.scaleLargeTimestamp for this, but
given sample offsets are relative and should always be
small (<<1s), it really shouldn't be necessary.
Issue: #3139
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164443795
This is required to correctly update the playbackInfo.periodId when
seeking close to the end of a period with ads, as the seek operation
leads to an immediate source info refresh when midroll ads are marked as
played.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164257099
This implementation runs as fast as possible by triggering a simplified
playback loop continuously without waiting. The class only supports a basic
use case with a single-period timeline, no timeline update, no seeks or other
user-initiated actions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164120420
Multiple timelines work as a wrapper around another timeline and forward
most of the method calls to the wrapped timeline. Added a base class meant to
be overridden which handles all the boiler-plate forwarding.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164117264
- Renamed some license URL related variables to keep consistency across the code.
- Added a new parameter to HttpMediaDrmCallback that enables forcing defaultLicenseURL as the license acquisition URL.
These classes maintain a shuffled order of indices allowing to query the
next, previous, first, and last indices. And also support inserting and
removing elements without changing the shuffled order of the rest.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164116287
This helper class required a scratch instance to write on. Such a scratch
instance may violate the immuatability of the timelines if used by multiple
threads simultaneously.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163992458
- Fix Ogg extractor to work without sniffing.
- Fix extractors to handle seek() before init().
- Add tests for both issues.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163992343
This is for consistency with what we do elsewhere;
specifically in FragmentedMp4Extractor.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163974960
The start code for H.262 codec-specific data may be across a packet boundary.
Before this change the offset passed to CsdBuffer.onData may have been before
the start point of the data in the newData buffer.
After this change, start codes are added directly to the CSD buffer when it's
filling and any start code bytes added by onData (at the end of a packet) are
discarded.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163943584
- Publish IMA extension
- Force IMA to use the correct version of the support library
- Add missing sr translations for repeat mode strings
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163705883
We do this in the dynamic case, and I think we've seen
a few GitHub issues where developers do this and don't
understand what they've done wrong (because the failure
comes later).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163688557
Currently the ExoPlayerWrapper is used to run tests using an ExoPlayer
implementation. Some properties of the test are set in the constructor, some
are set by overloading the class, others are hard-coded in the
ExoPlayerWrapper class, and a mechanism similar to the existing ActionSchedule
is missing.
This change does the following:
1. Renames ExoPlayerWrapper to ExoPlayerTestRunner as it better reflects
its purpose.
2. Adds an internal Builder to easily set-up the test in a coherent way. This
allows to only set necessary test components while using defaults for the rest.
3. Integrate ActionSchedule.
4. Apply the new structure to the existing tests currently using ExoPlayerWrapper.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163186578
Prepend sequence headers to the next frame, instead of appending them to
the previous frame. Tested decoders like FFMPEG and Google's
Android/MPEG2 expects to read the sequence headers before the first
frame they apply to. When sequence headers are appended to the previous
frame, these are ignored and this leads to incorrect decoding.
There's no way to represent a beta in our integer versioning
scheme. I propose we just set it the same for all betas + the
stable release. The versioning for the demo app isn't that
important, so I've just put it directly to 2.5.0 as well.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162749130
SKIPPED can't be handled as CONTENT_RESUME_REQUESTED because after skipping an
ad there may be further ads to play in its ad group.
Remove workaround for handling unexpected playAd without stopAd, as the player
can instead recover when IMA sends CONTENT_RESUME_REQUESTED. This in turn fixes
handling of the case where playAd is called twice but IMA expects only the
first ad to play, when skipping a particular ad. (Add an ad tag where this
occurs to internal samples.)
Check whether a currently playing ad has been marked as played in
ExoPlayerImplInternal, and handle this case as a seek. This ensures that any
loaded ad periods are discarded in the case of CONTENT_RESUME_REQUESTED.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162610621
When an ExtractorMediaSource is used in a concatenation, and
probably when using repeat modes, it needs to produce multiple
ExtractorMediaPeriods during usage. Currently we fire a
source info refresh every time a new ExtractorMediaPeriod
instance prepares, which triggers ExoPlayer.EventListener's
onTimelineChanged method. In nearly all cases the timeline is
unchanged after the first ExtractorMediaPeriod is prepared.
This change suppresses these no-op changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162484234
A content period just before a postroll ad group with all ads played
was not being marked as the last media period in the timeline period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162471919
This is the first step towards facilitating Cast integration to ExoPlayer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162366198
When resetting a SampleQueue, by default the upstream format
is not cleared. This is necessary for progressive playbacks,
since (a) the formats never change, and (b) the extractors
only output them once. So when a seek occurs, it's necessary
to clear all sample data from the queue, but retain the current
upstream format.
Uniquely for HLS, the media in a SampleQueue that we may read
from can be in a format not supported by the consuming renderers.
We clear all the sample data from the queue in this case, but
not the upstream format. Since we have an optimization that
allows the upstream format to be read in advance of another
sample being written into the queue, this can result in an
unsupported format being read by a consuming renderer. This
change ensures the upstream format is correctly cleared in the
problematic case.
Issue: #3079
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162360267
The default behaviour stays the same as Clock.DEFAULT == SystemClock. And it
enables bandwidth measurements in tests with simulated clocks.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162350852
All implementations of SequenceableLoader already implement this method.
Moreover, all composite media periods contained an exact copy of an
implementation that now moved to CompositeSequencableLoader.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162349083
The FakeClock allows to simulate timing behaviour including sleep time
for test cases.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162345258
The position returned by getContentPosition() could be C.TIME_END_OF_SOURCE.
Fix the content position stored in MediaPeriodInfos for postroll ads to be the
duration of the containing period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162322339
We currently read at most 5 packets at a time from the
extractor input. Whether this is inefficient depends on
how efficiently the underlying DataSource handles lots
of small reads. It seems likely, however, that DataSource
implementations will in general more efficiently handle
fewer larger reads, and in the case of this extractor
it's trivial to do this.
Notes:
- The change appears to make little difference in my
testing with DefaultHttpDataSource, although analysis
in #3040 suggests that it does help.
- This change shouldn't have any negative implications
(i.e. at worst it should be neutral wrt performance). In
particular it should not make buffering any more likely,
because the underlying DataSource should return fewer
bytes than are being requested in the case that it
cannot fully satisfy the requested amount.
Issue: #3040
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162206761
If seek is called for a non-seekable period, when the period is prepared the
start position will be updated from the seek position to zero. Because the
start position is part of the renderer offset for the first loaded period
holder, after the update the renderer offset start position and the new start
position would no longer cancel out, leading to the player position being
negative.
The first period holder's renderer offset is the fixed base offset (60 seconds)
plus its start position, but the start position is always subtracted. Avoid
subtracting the start position for the first period holder so that when it
changes there is no need to update the renderer offset.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162188133
This enables adaptive media test cases using TrackGroups with multiple
Formats.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162182005
This allows to create extensions of FakeDataSet and also simplifies the
FakeDataSource class.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162180952
Also move to using an array to hold the SampleQueues,
as we've moved to doing in ExtractorMediaPeriod.
Issue: #551
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161972990
drmInitData can be null in DASH if all of the init data is
specified at the manifest level instead. I took a look at
injecting the manifest format into the extractors, so that
we can actually copy the scheme type into it, but that's
at least non-trivial enough to delay for a subsequent CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161956246
On an old version of okhttp, opening connection clears the thread interrupt flag silently. This is a workaround
to reduce the effect of the bug.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161784435
ParsableBitArray.readBit in particular was doing an excessive
amount of work. The new implementation is ~20% faster on desktop.
Issue: #3040
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161666420
Really low hanging fruit optimization for TS extraction.
ParsableBitArray is quite expensive. In particular readBits
contains at least 2 if blocks and a for loop, and was being
called 5 times per 188 byte packet (4 times via readBit). A
separate change will follow that optimizes readBit, but for
this particular case there's no real value to using a
ParsableBitArray anyway; use of ParsableBitArray IMO only
really becomes useful when you need to parse a bitstream more
than 4 bytes long, or where parsing the bitstream requires
some control flow (if/for) to parse.
There are probably other places where we're using
ParsableBitArray over-zealously. I'll roll that into a
tracking bug for looking in more detail at all extractors.
Issue: #3040
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161650940
This CL also makes DefaultTrackSelector take it into account when RendererCapabilities
sets it to unsupported.
A following CL could add a DefaultTrackSelector parameter to force DRM "known support" for specific track types.
Issue:#1661
Issue:#1989
Issue:#2089
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161556467
Let's do it this way for now. Note there's an implicit
assumption in here that non-AV tracks consist of only
key-frames, but I think we'll not encounter any issues
in the real world as a result, we already make this
assumption in ChunkSampleStream, and actually tagging
every queue with this information explicitly is a very
painful amount of plumbing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161545383
Once background and resuming is supported, the ads loader will be kept when the
player is destroyed and recreated. Move the state relating to the structure of
ads and what ads have been loaded/played out of the media source and into the
loader so the information is not lost when the source is released, in
preparation for supporting background and resuming.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161503571
This option allows to move the currently playing media source to another position
and also to move other media source without creating a new MediaSource object.
Issue:#1706
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161402022
1. maybeRenotifyVideoSizeChanged should report reported* variables
2. Add check into maybeNotifyVideoSizeChanged to suppress reporting
in the case that the width and height are still unknown.
Issue: #3007
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160879625
This cleans up test the TestUtil class that in large parts consisted of
assertions for Extractor tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160829066
The deprecated methods will be removed as soon as HLS is migrated
to use the new ones.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160827936
This also ensures that TimelineAsserts only contains assert methods.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160827271
They serve the same purpose. One was defined as single window, multi-period
timeline, while the other was a multi-window, single-period-each timeline.
The combined FakeTimeline uses TimelineWindowDefinitions which allow multi-
window, multi-period fake timelines.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160808844
It was a bit strange how it returned something via the return
value and something else via the "out" variable, and doing it
this way wasn't even saving any allocations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160645640
Fake ExoPlayer componenets used within ExoPlayerTest.java can be useful for
other test classes and are therefore made available in testutils.
They can also be merged with other existing fake components.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160632908
Some parts of TimelineTest provided common assertions and helper classes for
other tests. As such, they better fit into testutils. In line with other
assertion methods, the TimelineVerifier class has been converted to a set of
static assertion methods.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160629797
(Related to GitHub #1706)
When the timeline becomes empty, the playback state transitions to "ended".
When the timeline becomes non-empty again, exceptions are thrown because MSG_DO_SOME_WORK is still regularly sent and media periods are getting prepared.
This change ensures that no MSG_DO_SOME_WORK messages are sent in "ended" state.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160537147
These changes are in part related to handling playback of mixed clear
and encrypted content, where we might want to use a secure decoder
throughout, but only have drm init data and only care about the state
of the DrmSession during playback of encrypted parts.
- requiresSecureDecoderComponent became unnecessary when we added
ExoMediaCrypto, which provides a layer in which requiresSecureDecoderComponent
can be overridden.
- Relaxed requirements for obtaining the MediaCrypto. It's helpful
to allow retrieval in the error state, since it can be used to
instantiate a decoder and play clear samples.
- Deferred throwing of errors in renderer implementations. As long as
we can get a MediaCrypto, we should init the codec. We can also
play clear samples without failing if playClearSamplesWithoutKeys is
true, regardless of the errors state.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160536365
This base class will be used to extend HlsDownloaderFactory from.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160523335
(GitHub issue #1706)
The media source allows adding or removing child sources before and after prepare() was called.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160516636
This is currently happening after toggling the repeat mode. This is line with
the rest of the implementation which requires a seek operation to resume
playback.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160516449
This also adds support for seeking in periods with midroll ads.
Remove Timeline.Period.isAd.
Issue: #2617
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160510702
Two of MediaPeriod's methods are only called after the media period has been
prepared. Added this to JavaDoc of these method to simplify implementations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160510373
Add a compatibility AudioAttributes class so that the app can specify
audio attributes in the same way before and after API 21.
Deprecate SimpleExoPlayer.setStreamType. Add
SimpleExoPlayer.setAudioAttributes and MSG_SET_AUDIO_ATTRIBUTES.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160408574
Both methods make extensive use of MediaPeriodHolder internals.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160386401
Also update the time bar to show ad markers using in-period ads and
remove support for periods being marked as ads.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160382805
With this change, it becomes possible to depend on ExoPlayer
locally in settings.gradle by doing:
gradle.ext.exoplayerRoot = 'path/to/exoplayer/root'
apply from: new File(gradle.ext.exoplayerRoot, 'core_settings.gradle')
You can optionally add a prefix onto ExoPlayer's module names
by adding:
gradle.ext.exoplayerModulePrefix = 'prefix'
Issue: #2851
Issue: #2974
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160277967
It's currently difficult to use ExoPlayer modules in other gradle
projects because they rely on constants and dependencies defined
in our own top level gradle file. This change moves the constants
into a separate file referenced directly from each module. It also
removes the need for the top level gradle file to declare a
dependency on com.novoda:bintray-release. This is now only needed
if "exoplayerPublishEnabled = true" is specified.
Issue: #2851
Issue: #2974
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160272072
This will allow MediaSources to provide MediaPeriods that correspond to ad
breaks in a timeline period rather than content for a timeline period, in a
future change.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160267841
This better reflects the purpose of this flag and makes code more readable.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160246573
Getting active status of caching is needed to display on UI. Instead of a listener interface polling was chosen because of simplicity and better suits to UI refreshing.
CachingCounters.downloadedBytes was updated after whole data is downloaded. Now it's updated for each read into buffer. Buffer length defines how finer these updates are.
CachingCounters.totalBytes is added so UI can display a progress bar.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160142048
This change allows you to enable/disable tracks within which
all samples are key-frames without any re-buffering (e.g. audio,
text and metadata). This effectively reverts V2 back to the
behavior in V1, only this time we're doing it properly. []ly
disabling/enabling, or disabling/enabling whilst paused, no longer
cause samples to get "lost" between the source and renderers.
Note it also becomes really easy to support a few other things,
although support is not exposed in this change:
- Enable/disable video tracks without any re-buffering, by
changing the toKeyframe argument passed to discardTo to true.
- Retain media in the buffer for some time after it's been played
(e.g. to support a single back-5s-seek efficiently), by
subtracting the desired back-buffer time from the value that's
passed to discardTo.
Issue: #2956
Issue: #2926
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160128586
Make DrmSessionException takes in Throwable cause instead of Exception cause, which is more limiting and doesn't add any benefit.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160121486
The if clause was never executed because nextLoadingPeriodIndex is set
to C.INDEX_UNSET instead of loadingPeriodIndex + 1.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159948661
It's no more complicated to avoid it, and according to the
Art team it should be faster without.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159816746
- If we have <s1>garbage<s2> and discard <s2>, throw away
the garbage too.
- Cleanup some documentation to consistently refer to the
queue as "queue" rather than "buffer".
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159816309
This will extend our CENC modes support to cbcs and cens. The change was
not split into two different CLs due to lack of test content for
default initialization vectors, aside from AES-CBCS encrypted ones.
Issue:#1661
Issue:#1989
Issue:#2089
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159810371
This was broken prior to my recent changes, since
largestDequeuedTimestampUs was only being updated in readData.
It should have been updated in the skip methods. as well.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159704945
CacheAsserts contains cache assertion methods for testing. It's easier to use in tests than DashDownloadTestBase which requires to be extended.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159688808
It's a bit messy at the moment with the deprecated methods
in there, but on the read side the new set of methods is as
follows:
Modifies the start of buffer:
- discardTo(time, keyframe, ...) [this is new]
- discardToRead()
- discardToEnd()
Modifies the read position:
- rewind()
- advanceTo(time, keyframe, ...) [this is a generalization of skipToKeyframeBefore]
- advanceToEnd() [previously called skipAll]
- read(...)
Which seems quite nice and self-consistent, and is powerful
enough for everything that we need to do as we move MediaSource
implementations over to the new methods.
TODOs for subsequent changes:
- Re-order methods in the two classes so that they're actually in
the same order, and move the deprecated ones out of the way
- Enhance SampleQueueTest to also cover new functionality, as we
start transitioning MediaSource implementations over to use it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159688660
Made the method copy all of the fields of DataSpec in to the new instance. Also converted
it to an instance method of DataSpec for ease of usage, discovery and maintenance.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159670314
Error prone check doesn't like we pass a variable named 'end' as start parameter and 'start' as end.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159567308
At the moment, only CENC-defined scheme types are known values.
This will allow having more information about the encryption
scheme through the format, which in turn will allow more informed
decisions on format support.
Issue:#1661
Issue:#1989
Issue:#2089
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159538907
A few components in ExoPlayer requires playback looper to operate (such as:
DrmSessionManager#acquireSession), so this CL add back getPlaybackLooper()
to facilitate such cases.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159416012
(Fixing GitHub issue #2923)
Cuurently, ClippingMediaSource issues an initial discontinuity. This causes the
renderers to be disabled and re-enabled when this media source is used in a sequence
with other sources (or in a loop).
This change disables the use of an initial discontinuity for audio-only media under
the assumption that audio streams have random access capabilities.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159221963
Use an actual class for the stub media source instead of an anomymous class.
Allows to call assertReleased() on that class.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159109143
Previously, writeAllocationNode was not advanced to the
terminating node when finishing writing sample data that
fills exactly up to the end of the current write node.
This wasn't actually broken, but is confusing because it
causes edge cases where the start/read references could
temporarily refer the node after the current write node.
This change advances the write reference in this case,
removing this confusion and bringing the implementation
in line with what the design doc says happens.
Also making some simplification and consistency changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159099522
This will allow us to maintain a reference to the middle
of the queue, which is necessary to efficiently support
decoupling the read position from the start of the buffer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158839336
(Preparation for GitHub issue #1706)
AbstractConcatenatedTimeline repeatly calls methods of its implementation to
query a specific child timeline. This may be inefficient if the implementation
repeatly executes the same code to find the timeline.
Changed the class such that it now queries all information at once using a meta
data class. As all methods need at least two of four variables anyway, this
doesn't generate unnecessary overhead.
Also generified the UID for the child indices to allow new implementations to
use some other UID besides the index.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158711979
The same effect can be achieved by checking the isLoading variable of ExoPlayerImplInternal
because this variable is in almost all cases set simultaneously with loadingMediaPeriodHolder.needsContinueLoading.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158697948
Separate MediaPeriodHolder.index and MediaPeriodHolder.periodIndex, so that the
latter is always a period index (which may repeat or jump) whereas the holder
index increases by one each time an item is added to the period holder queue.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158497639
Currently, media is discarded from DefaultTrackOutput
and SampleMetadataQueue as soon as it's been read. In
upcoming changes we'll decouple discard and read. This
will make it possible to retain already-read media in
these buffer classes, and allow the read position to
be moved backward as far as media is retained. This is
important for fixing an edge case around 608/EMSG
tracks, and could also underpin future features like
allowing retaining of X-seconds past media in the
buffer.
This change renames some variables and methods to
prepare for the upcoming changes. read/write indices
are renamed to start/end. The upcoming changes will
add a read index that's between the two. isEmpty is
inverted and renamed to hasNextSample, since it will
be possible to not have a next sample (because the
read index == end index) but for the buffer to not
be empty (because start index < read index).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158409630
It's pretty big as an inner class, and is going to get a
little more complicated. I think it makes sense to be
able to consider it in isolation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158393754
This allows other tests to reuse the util classes without having to link to playbacktests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158214560
This prevents strange behaviors for streams that changes the track declaration
order in the PMT.
NOTE: This should not change ANY behavior other than the one described above.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158140890
- Return early if the selection is unchanged.
- Remove unnecessary variables.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158138187
When updating track selection, we should only revert back from ideal
track selection to current track selection if the currently selected
track is not black-listed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158135644
1. Remove tools:replace in manifest files. This attribute is only needed to establish priority when two manifests are merged and have the same attribute with different values.
As this is not happening here, the attributes can be removed.
2. Some BUILD files also define a deprecated manifest merge strategy different from the android default merge strategy. For consistency these are set to "android'.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158075128
This avoids calling getDecoderInfo repeatedly in the case
where shouldInitCodec return false (e.g. because we don't
have a surface and cannot instantiate a dummy surface).
Issue: #677
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157847702
This will cause the test to exercise the code path of
instantiating a DummySurface, rendering to it for 10
seconds, then re-targeting the real surface again. For
secure content tests the code path is only exercised if
DummySurface.SECURE_SUPPORTED is true. The logic for
checking this is within MediaCodecVideoRenderer itself,
rather than being part of the test.
Issue: #677
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157833026
ExoPlayer.setRepeatMode should be preferred. Deprecate
the constructor and update the relevant documentation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157829207
This is necessary to make sure that the correct thing happens
where MediaCodecInfo.adaptive is queried directly (for example,
MediaCodecVideoRenderer uses the field to determine how to size
input buffers). Also disable adaptive on Nexus 10.
Issue: #2806
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157583473
We do this everywhere for index based seeking already.
Issue: #2876
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157568788
Use AUDIO_UNKNOWN instead. This is in line with our handling
of video tracks with VIDEO_UNKNOWN.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157209428
This fixes transitioning into the ended state if we see
endOfStream from the chunk source whilst in the pending
reset state. Prior to this fix we'd still be pending a
reset, and so readData would never allow EOS to be read
by the consuming renderer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157101755
*** Reason for rollback ***
This change may silently introduce bugs where both parameters are acceptable in both places. It's decided that the gain isn't worth the risk.
*** Original change description ***
Make the error messages the first parameter in Assertions methods to match JUnit methods
Reverse parameter order creates a slight confusion.
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156844728
Expose the stream offset to BaseRenderer subclasses.
Issue: #2267
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156837514
([]
This change has been automatically generated by an Error Prone check that
detects incorrect argument ordering on calls to assertEquals-style methods. See
[]
Cleanup change automatically generated by javacflume/refactory
Refactoring: third_party/java_src/error_prone/project/core/src/main/java/com/google/errorprone/bugpatterns/argumentselectiondefects:AssertEqualsArgumentOrderChecker_refactoring
Tested:
TAP --sample for global presubmit queue
[]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156739144
(Related to GitHub Issue #2577)
Added test to ExoPlayerTest which changes the repeat mode during playback.
Test verifies that ExoPlayer shows the periods in the intended order.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156168166
- Call onDisabled last. onDisabled really shouldn't be doing
anything with the stream, so pretty sure this is fine (and
guarantees the stream is cleared properly even if onDisabled
throws a RTE).
- Remove super.onDisabled calls from Text/Metadata renderers.
This is just for consistency; we don't make such calls in
other direct descendants of BaseRenderer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156130640
If a timeline update removed periods at the end of the timeline which
had been buffered, handleSourceInfoRefreshed would call
getNextPeriodIndex and get back -1 for the last period holder in the
new timeline. Then isLastPeriod(-1) could throw.
Fix this behavior so that the remainder of the timeline is discarded.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156061016
Checking the expected next/previous window indices and if the correct window
or period gets returned.
TimelineTest defines mock classes and verification methods used by the specific
implementation tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155727385
When readingPeriodHolder and playingPeriodHolder are both null, a
NullPointerException is thrown when trying to reassign readingPeriodHolder.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155635846
(Relating to GitHub issue #2577)
Changing the repeat mode during playback may require to discard or rebuffer
certain periods because the requested order of playback changed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155600910
(Relating to GitHub Issue #2577)
The Timeline base class provides the default implementation.
Timeline wrappers (e.g. ClippingTimeline, ConcatatedTimeline) forward all
requests to the respective inner timelines. Some like ConcatenatedTimeline add
their own additional logic to bridge between the child timelines.
In addition, ConcatenatedTimeline and LoopingTimeline now have a common
abstract base class as they share most of their code.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155509269
Even though this is not strictly spec compliant, this will make exoplayer
behave like it used to before multiple program support. Developers
who want to take advantage of the multiple program support are probably
less than the ones who only want their stream to "just work". This is
particularly useful for streams obtained after a filtering component,
like a tv tuner.
Issue:#2757
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155486122
This will allow supporting more encryption schemes. Including some
that require more encryption data, like the encryption pattern.
Issue:#1661
Issue:#1989
Issue:#2089
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155481889
This is most commonly caused by malformed media, where
the media indicates that something we need to make an
allocation for is *really huge*. Failing playback is
appropriate for this case; killing the process is not.
Issue: #2780
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155408062
Added repeat mode toggle buttons to UI. Current mode gets forwarded to
Exoplayer instance, but without playback behaviour changes yet.
Translations for button descriptions are also missing - this will be another CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155386549
The default byte order for ByteBuffers is big endian, but platform decoder
output buffers use native byte order. AudioProcessors handle native byte order
input/output.
When using a software audio decoding extension the Sonic audio processor would
receive big endian input but was outputting to a native byte order buffer,
which could be little endian. This mismatch caused audio output to be
distorted.
After this change both platform decoder and extension decoder output buffers
should be in native byte order.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155320973
If the codec isn't adaptive, there's no need to accommodate
the width/height/input-size of streams that don't have the
same resolution as the current stream. This is because we'll
always need to instantiate a new codec anyway.
Issue: #2607
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155194458
(Relating to GitHub Issue #2577)
All getter, setter and callbacks have been added and value of repeatMode is
passed to getNextXXXIndex methods.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155071985
A DummySurface is useful with MediaCodec on API levels 23+.
Rather than having to release a MediaCodec instance when the
app no longer has a real surface to output to, it's possible
to retain the MediaCodec, using MediaCodec.setOutputSurface
to target a DummySurface instance instead. When the app has
a real surface to output to again, it can call swap this
surface back in instantaneously. Without DummySurface a new
MediaCodec has to be instantiated at this point, and decoding
can only start from a key-frame in the media.
A future change may hook this up internally in MediaCodecRenderer
for supported use cases, although this looks a little awkward. If
this approach isn't viable, we can require applications wanting
this to set a DummySurface themselves. This isn't easy to do with
the way SimpleExoPlayerView.setPlayer works at the moment, however,
so some changes will be needed either way.
Issue: #677
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154931778
Looper.myLooper(), the default looper, may be null in background threads. This adds a fallback to use the main app looper.
This will allow ExoPlayer instances to be built in background threads in Photos.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154845446
Using the new getNextWindowIndex method of Timeline, LoopingMediaSource now
uses a InfinitelyLoopingTimeline which does not unroll the windows to
157 million iterations but just starts from the beginning. If an explicit
number of iterations is given, we still unroll.
This change also allows multi-window timebars to show infinitely looping
playlists correctly.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154817554
(Preparation for Repeat Toggle Function - GitHub Issue #2577)
In addition, Timeline now also got a getPreviousWindowIndex and a
getNextPeriodIndex method with default implementations.
Changed ExoPlayerImplInternal and PlaybackControlView to use these
methods at all occurances of period and window index operations.
Note: Does not include repeat mode yet and no timelines are actually
using it so far. Please wait for the next CLs for this.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154520664
To inject custom renderers into SimpleExoPlayer, developers
currently need to extend SimpleExoPlayer and override the
renderer building methods. This is in contrast to the rest
of the library, where we use proper injection. This change
restores consistency. I think it's fine to make
SimpleExoPlayer final again, but if we find people extending
it for non-renderer purposes, we can revert that part of the
change.
ExoPlayerFactory now has analogous methods for the simple
and non-simple cases, which is a nice outcome.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154295726
Fixes the following issues:
1. When a surface is set, it's expected that the renderer will
notify video size + when a frame is rendered to it. This is true
even if the surface isn't changing. Right now this is achieved
by setting renderedFirstFrame to false, but this is problematic
in the case that the surface isn't changing because (a) it will
force rendering of a subsequent frame to the output even when
paused, which is incorrect, and (b) isReady will return false
until this occurs.
2. When the surface really is changing, isReady can return false
until the first frame has been rendered into the new surface, which
will break seamless surface switching. This change allows isReady
to return true up to allowedJoiningTimeMs for this case.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154171111
* colorSpace, colorRange and colorTransfer are relevant to all videos.
* The rest of the fields are relevant only to HDR videos.
* Tested on a prototype device that decodes VP9 profile 2, 10 bit.
* The Webm spec spells color as 'colour' so the webm id reference use the same spelling.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154098189
Prior to this change, the only way to switch SimpleExoPlayerView
was to do:
oldView.setPlayer(null);
newView.setPlayer(player);
This would cause the video renderer to have to transition through
oldSurface->noSurface->newSurface, which is inefficient (noSurface
requires platform decoders to be fully released).
After this change we support:
newView.setPlayer(player);
oldView.setPlayer(null);
This results in direct oldSurface->newSurface transitions, which are
seamless on Android M and above. The change also adds some robustness
against developers ending up with strange behavior as a result of
clearing the player from a view in a different ordering than we expect
w.r.t. registering of other listeners.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154044976
This class is unnecessary; you can simply pass a thread
priority to HandlerThread's own constructor. It's also
broken, since HandlerThread.run() immediately overrides
the priority being set!
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=153461225
If AudioTrack.setPlaybackParameters was called before initialization (for
example, when an audio renderer is enabled) the parameters would actually be
dropped, because configure calls reset, which didn't apply draining playback
parameters if the track was not initialized. It would then overwrite the
draining parameters with the current parameters.
Set the playback parameters directly (without draining) for uninitialized tracks
so that the call to setPlaybackParameters in configure is a no-op.
Also, reset the stored channel count and sample rate when the audio processor
is released so that configure returns true when it is next used, which makes
sure that it gets flushed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=153078759
The track initialization data of Tx3g includes default style values for
font styles, colour, and font family. Additionally the decoder now supports
vertical subtitle placements other than the Tx3g default of 85% video height.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152930057
The idea of using reflection was so that a developer could
delete a package they didn't want and have everything else
still compile. However, a developer doing this is likely
building from source, in which case editing the factories
too is pretty trivial.
Removing the reflection makes specifying extractor flags
via the default factory easy, and removes the need for
special proguard config.
Issue: #2657
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152810423
Extended Tx3gDecoder to read additional information after subtitle text.
Currently parses font face, font size, and foreground colour.
Font identifier and other information provided in subtitle sample description
not yet supported.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152793774
When no video tracks or renderers are present, attempt audio adaptation.
Issue:#1975
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152708422
I've also removed unnecessary "empty" cases, since to add them
everywhere would bloat the code quite a lot. Note that
new String(new byte[0], 0, 0, encoding) is valid and will produce
and empty string.
Issue: #2663
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152697288
This allows propagating format changes to the track output.
Issue:#2552
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152672983
ExoPlayerImpl.prepare() replaces the timeline with an empty timeline. After this
happens, MSG_SOURCE_INFO_REFRESHED could be handled on the main thread and
could relate to the old source, so the player could expose a stale timeline.
Count pending prepares in ExoPlayerImpl so that source info refreshes can be
suppressed until preparation actually completes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152496255
- Removed the PES_STRIPPED flag. It's unnecessary. We can strip
PES in the TS extractor instead.
- Made nearly all of the object classes in DvbParser immutable.
Else it's non-obvious that none of this state can be mutated.
- Made a a lot of the methods in DvbParser static for the same
reason.
- Removed unnecessary null checks, code that was never executed,
unused fields etc.
- Add proper flushing of DvbParser, to prevent corrupt output
following a seek.
Only enable multi-window mode when the duration of every period in the timeline
is known. Also, remove the warning logged when there are too many windows as it
doesn't add much.
The player's current period index was not masked while there were
unacknowledged seeks. This led to the displayed position jumping, between when
seekTo was called (after which the position would be masked but not the period
index) and the seek being acknowledged (at which point the time bar's position
would jump back to the seek position, due to the period index being resolved).
Mask the period index, like the window index, to fix this behavior.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152116040
Start draining the audio processors when the playback parameters change,
and when draining completes use the written frame count and next input
buffer presentation timestamp as an offset for applying the new playback
speed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151800074
This change also ensures that format changes are read whilst the
renderer is enabled but without a codec. This is necessary to
ensure the drm session is updated (or replaced).
Updating the format is also needed so that the up-to-date format is
used in the case that the codec is initialized later due to the
surface being set. Previously, if an ABR change occurred between
the format being read and the surface being attached, we would
instantiate the codec and then immediately have to reconfigure it
when as a result of reading the up-to-date format. For a non-adaptive
codec this resulted in the codec being immediately released and
instantiated again!
Issue: #2582
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151608096
This is the boring part of a larger change that fixes
how video renderers behave when surfaces are attached and
detached whilst they're enabled or started.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151563031
'library-core' is still affected by https://code.google.com/p/android/issues/detail?id=226070
Code coverage report can be generated for the rest of the modules by:
./gradlew :[module name]:createDebugCoverageReport
Report is generated under:
[module folder]/buildout/reports/coverage/debug
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151448536
If the super method has the annotation on an argument, then
the overriding method should have it too.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151440313
- Validate frames for majorVersion 2 and 3 as well as 4
- Don't throw if top bit of frameSize is non-zero.
Issue: #2604
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151348836
The only case where we should pass false is if we want to know
whether the passed time is within the buffered media. This is
relevant within seekTo implementations only.
This is related to (but does not fix) issue #2582
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151315676
Also move it closer to the ExoPlayer code style.
Note: This change is intended to be purely cosmetic.
Issue: #26
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151307575
Also add an isAd flag to Timeline.Period so that periods can be declared as
containing ads. The times of these periods are indicated using ad markers in
the new TimeBar.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151116208
Add methods to ExoPlayer for setting/getting the playback speed, using
SonicAudioProcessor.
Remove PlaybackParams support, as the AudioTrack timestamp does not work
reliably on Marshmallow. The platform also uses Sonic and performance
should be comparable between the Java and native versions on recent Android
runtimes.
In a later change, SonicAudioProcessor will be made public so it can
be used in conjunction with other processors.
Issue: #26
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151027121
The way it was before worked, but it's not really documented
that DrmSession methods implemented by DefaultDrmSessionManager
can be called after the session has been released, and it feels
wrong to do this.
At some point we should probably consider moving the DrmSession
part of DefaultDrmSessionManager into an inner class, to force
usage in the "normal" way.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151003855
Notes:
- Now only generating a single module Javadoc task for the
release variant.
- Combined Javadoc now includes extensions. VP9 is excluded
for now since it's failing for an unknown reason.
Issue: #2139
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150865589
Notes:
- The VP9 one is failing claiming that the util package
doesn't exist and that LibraryLoader cannot be found.
Unsure why, since it appears to be setup exactly like
other extensions (e.g. Opus) that does work.
- @link across modules will not work when generating
Javadoc for a single module. This is WAI. I subsequent
change will add an aggregated Javadoc generator that
will generate Javadoc for all modules together and
apply cross module @link correctly.
Issue: #2139
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150864273
Also renamed releaseResources->release to be consistent with the
rest of the library, and added some synchronization to ensure
correct usage.
Issue: #2139
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150753414
1. Move entire library from v2/library/ to v2/library/core
2. Add v2/library/all that depends on v2/library/core
Issue: #2139
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150455693
