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
