The number is shelved in calls to queue.clear() to keep it for the next
media period. However, the queue may also become empty by repeated calls to
advancePlayingPeriod which may happen when seeking to an unprepared period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=205376036
Also fixed showing "remove notification" when download is completed.
Issue:#4469
Issue:#4488
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203927268
It's no longer text specific (it's used for metadata as well, and
in theory could apply to any stream in which samples contain multiple
sub-samples)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203767825
Viewport constraints apply to adaptive content even if the
actual playback isn't adaptive (i.e. because the selector
ends up making a fixed track selection).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203726831
If there is only one track, we can assume that both boxes refer to the same track
even if the track indices don't match.
Issue:#4083
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203485872
MediaDrm.provideXResponse methods only accept the response
corresponding to the most recent MediaDrm.getXRequest call.
Previously, our code allowed the following incorrect call
sequence:
a = getKeyRequest
b = getKeyRequest
provideKeyResponse(responseFor(a));
This would occur in the edge case of a second key request
being triggered whilst the first was still in flight. The
provideKeyResponse call would then fail.
This change fixes the problem by treating responseFor(a)
as stale. Note that a slightly better fix would be to
defer calling getKeyRequest the second time until after
processing the response corresponding to the first one,
however this is significantly harder to implement, and is
probably not worth it for what should be an edge case.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203481685
Both boxes should contain the same list of track indices. However, if only one
track index in each list does not match, we can just assume that these belong
together.
Issue:#4477
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=203481258
It's quite hard to find the defaults currently. Placing them
on each variable makes them easier to find.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202495929
Currently we immediately stop searching after we found one video and one
audio track. This change adds some leeway to detect additional tracks.
Issue:#4406
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=202455491
Allows DrmInitData to carry a license server URL when the media declares one.
Issue:#3393
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199643743
When switching from Stack to ArrayDeque, calls to add() need to be replaced by
calls to push() because ArrayDeque treats the first element in the list as the
top of the stack.
String.split() has counterintuitive default behavior; see
https://github.com/google/error-prone/blob/master/docs/bugpattern/StringSplitter.md.
I've switched usages to pass limit = -1 argument, which means empty elements are
no longer removed from the end of the returned array.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199472592
If a MediaPeriod uses a Loadable, then there are typically
reference chains of the form:
LoadingThread[GCroot]->Loadable->MediaPeriod->Player
Where the player is the MediaPeriod callback. When the
player is released, this reference chain prevents the
player from being GC'd until Loadable cancellation
completes, which may not always be fast. This in turn
will typically prevent the application's activity from
being GC'd, since it'll normally be registered as a
listener on the player (directly or indirectly via
something like a view).
This change mitigates the issue by removing references
that the MediaPeriod holds back to the player. The
MediaPeriod will still not be eligible for GC, but the
player and application activity will be, which in most
cases will be most of the leak (in terms of size).
Issue: #4249
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199143646
This happens when the device screen is locked.
This fixes a previous attempt to fix the problem.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199130325
This helps to use the AnalyticsCollector without SimpleExoPlayer. Currently,
that may be problematic, if the contructor needs the player, but in order to
create the player, one already needs the AnalyticsCollector as a listener for
the renderers.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=199105012
This simplifies Loadable implementations, and also removes the
possibility of an incorrect Loadable implementation causing the
wrong Loader.Callback method being called (perviously, for the
correct method to be called, we relied on isLoadCanceled being
implemented correctly).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198871133
There is the small (but unlikely) chance that the uids clash because the
Objects have the same hash code.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198855724
The bug here was that we'd create a VideoFrameReleaseTimeHelper
using whatever context DefaultRenderersFactory has, and it would
then hold a reference to that context via DisplayManager. A leak
could then occur if the player outlived the life of the context
used to create it (which would be strange/unusual, but not
impossible).
Issue: #4249
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198747599
As highlighted by the ref'd issue, we can end up with
memory leaks if Loadable.load implementations take a long
time to return upon cancelation. This change cuts off one
of the two problematic reference chains.
This doesn't do much about the ref'd issue, since there's
a second reference chain that's much harder to deal with:
Thread->LoadTask->loadable. But since it's easy just to
cut this one off, I figure it makes sense to do so.
Issue: #4249
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198735386
This makes the requirement that all calls are made on one thread more
explicit and also mentions this in the Getting Started guide.
Issue:#4278
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198694579
Set content length and redirect uri in a single transaction.
New: Fixed the code where DataSpec.uri is set to null in []
Automated g4 rollback of changelist 196765970.
*** Reason for rollback ***
Fixed the code where DataSpec.uri is set to null in []
*** Original change description ***
Automated g4 rollback of changelist 194932235.
*** Reason for rollback ***
This CL breaks the playability of Mango's offlined progressive videos.
*** Original change description ***
Set content length and redirect uri in a single transaction
NORELNOTES=true
NO_BUG
***
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=198370211
