Can happen if the load position falls behind in every playlist and
when we try to load the next segment, the adaptive selection logic
decides to change variant.
Issue:#5816
PiperOrigin-RevId: 245923006
This resolves some naming confusion that previously existed
as a result of DownloadThread also being used for removals.
Some related variables (e.g. activeDownloadCount) would refer
to both download and removal tasks, whilst others
(e.g. maxParallelDownloads) would refer only to downloads.
This change renames those that refer to both to use "task"
terminology.
This change also includes minor test edits.
PiperOrigin-RevId: 245913671
[Problem]
There are 3 services / modes transported on line 21:
- Captioning
- TEXT (generally not program related)
- XDS (eXtended Data Services)
Bytes belonging to the unsupported modes are interleaved with the
bytes of the captioning mode.
See Chapter 7, Chapter 8.5 and Chapter 8.6 of the CEA608 Standard for
more details.
[Solution]
Drop all bytes belonging to unsupported modes.
[Test]
- All streams containing only captioning services should not be influenced
- Test all 4 CEA 608 channels with live over-the-air content and
using all available TEXT and XDS streams.
There are no logic changes here. It's just moving code around and removing
the "internal" part of names where no longer required.
PiperOrigin-RevId: 245407238
We currently toggle the view in onTouchEvent ACTION_DOWN which is non-standard
and causes problems when used in a ViewGroup intercepting touch events.
Switch to standard Android click handling instead which is also what most
other player apps are doing.
Issue:#5784
PiperOrigin-RevId: 245219728
The AndroidX bundled version (0.42) lags behind the most up-to-date public
release (0.44) making it more difficult to stay close to the actual head
revision which is used internally.
PiperOrigin-RevId: 244848568
This ensures we keep the loading period in sync with the the playing period in
PlybackInfo, when the latter changes to something new.
PiperOrigin-RevId: 244838123
Also re-enable two of them, although note that the fix here is
not related to the flakiness that caused them to be disabled.
I'm re-enabling them since much has changed in DownloadManager,
and the hope is that these tests are no longer flaky.
PiperOrigin-RevId: 244826225
Experiments show this is beneficial for rebuffers with only minor impact
on battery usage.
Configurations which explicitly set a minimum buffer duration are unaffected.
Issue:#2083
PiperOrigin-RevId: 244823642
Before this change we'd release the audio track and create a new one as soon
as audio processors had drained when reconfiguring.
Fix this behavior by stop()ing the AudioTrack to play out all written data.
Issue: #2446
PiperOrigin-RevId: 244812402
- We had buildAddRequest and sendNewDownload. Converged to
buildAddDownload and sendAddDownload.
- Also fixed a few more inconsistencies, and brought the
action constants into line as well.
PiperOrigin-RevId: 244274041
- Listener based reporting of progress allows the content length
to be persisted into the download index (and notified via a
download state change) as soon as it's available.
- Moved contentLength back into Download proper. It should only
ever change once, so I'm not sure it belongs in the mutable part
of Download.
- Made a DownloadProgress class, for naming sanity.
PiperOrigin-RevId: 244242487
1. customCacheKey for DASH/HLS/SS is now asserted against
in DownloadRequest
2. Merging of event delivery in DownloadManager is very
tricky to get right and probably not a good idea
PiperOrigin-RevId: 244048392
Currently SimpleCache will touch cache spans whenever it reads
from them. With legacy SimpleCache setups this involves a potentially
expensive file rename. With new SimpleCache setups it involves
a more efficient but still non-free database write.
For offline use cases, and more generally any use case where the
eviction policy doesn't use last access timestamps, touching is
not useful. This change allows the evictor to specify whether it
needs cache spans to be touched or not. SimpleCache will only touch
spans if the evictor requires it.
Note: There is a potential change in behavior in cases where a
cache uses an evictor that doesn't need cache spans to be touched,
but then later switches to an evictor that does. The new evictor
may temporarily make sub-optimal eviction decisions as a result.
I think this is a very fair trade-off, since this scenario is
unlikely to occur much, if at all, in practice, and even if it
does occur the result isn't that bad.
PiperOrigin-RevId: 244005682
One goal we forgot about a little bit was to allow applications
to provide their own index implementation. This requires the
writable side to also be defined by an interface.
PiperOrigin-RevId: 243979660
ImaAdsLoader gets the player position after the app releases
the player to support resuming ads at their current position
if the same ads loader is reused.
PiperOrigin-RevId: 243969916
ShadowLooper -> ShadowLegacyLooper
ShadowRealisticLooper -> ShadowPausedLooper
ShadowBaseLooper -> ShadowLooper
And all public methods from ShadowLegacyLooper get pushed up to ShadowLooper
Pull Request: https://github.com/robolectric/robolectric/pull/4868
Copybara: OK
Also adjust Google3 tests using custom looper shadows where necessary.
Convert exoplayer to paused looper to eliminate reliance on custom shadows
PiperOrigin-RevId: 243839311
The removed condition only applies when prepare fails and no timeline was or
is known. We should keep a pending seek position in such a case. The internal
player does the same thing already.
PiperOrigin-RevId: 243819466
- Expose constructors that take DatabaseProvider. Deprecate those
that do not.
- Expose Cache.getUid. This will likely be used for naming of the
tables accessed by DefaultDownloadIndex .
PiperOrigin-RevId: 243637786
- Allows enforcing immutability, which in a future CL will allow
avoiding allocating a new array/list on every call.
- Also some left over doc cleanup from the DownloadState rename.
PiperOrigin-RevId: 243627352
The old domain automatically forwards to the new one. For consistency, change
all doc and code references regardless.
Also adds GitHub CNAME config file which configures our page for the custom
domain.
PiperOrigin-RevId: 243592110
handleSourceInfoRefreshed checks for various conditions which may trigger a
change in position. In all cases, we need to resolve the new position for ads,
and if the corresponding MediaPeriods already exist, perform the seek to the new
position.
This change simplified the code by
1. Moving all conditions in a single if-else structure which just determines
the new playback position. This makes it easier to read and to follow.
2. Doing the subsequent seek and position update in one final step to remove
duplicated code.
As a side effect, it also improves some edge cases. For example when skipping
an ad to an already prebuffered period, we now properly update the existing
prebuffered period.
PiperOrigin-RevId: 243588014
- Make a best effort to avoid posting MSG_DOWNLOAD_THREAD_STOPPED
if the internal thread has already quit. Doing so is harmless,
but causes an error in Logcat. We used to generate this warning
quite a bit in ExoPlayerImplInternal as well, and we got quite
a few issues filed about it, so best to avoid it if possible.
- Null out the back reference DownloadThread holds to its manager
on release. This avoids a potential issue where a download thread
can prevent GC of its manager if it doesn't cancel quickly.
There's similar logic (with a similar comment) in Loader.LoadTask.
PiperOrigin-RevId: 243365143
- Rename getAllDownloads to getCurrentDownloads to make it clear
that it doesn't include completed and failed downloads
- Change getDownloadCount to isWaitingForRequirements, which is
what it's used for. Added TODO to make it returns the right thing
PiperOrigin-RevId: 243257856
If the returned retry delay is unset, we should use a DONT_RETRY_FATAL action
instead and dispatch the event with the "canceled" flag.
PiperOrigin-RevId: 243251554
Non-trivial download state transitions are currently split across
DownloadManager and Download. These transitions are part of the
same state machine, so it's clearer if they're all in the same place
(i.e. DownloadManager, since this is the component that transitions
downloads between states).
PiperOrigin-RevId: 243249915
The only state DownloadInternal holds is duplicate of state contained
in Download, but can confusingly be temporarily out of sync. This is
error prone because it's easy to use the wrong variable (e.g.
download.state vs state). DownloadInternals methods are called into
and call out into DownloadManager, which makes some code paths that
are quite hard to follow.
It's possible to simplify DownloadManager quite a lot by removing the
duplicated state in DownloadInternal, at which point DownloadInternal's
methods flatten into DownloadManager, which can just hold an internal
list of Downloads directly.
This is a first step, which makes it clear that DownloadThready only
needs its immutable DownloadAction + an isRemove flag.
PiperOrigin-RevId: 243245288
Put methods into a more sensible order (the same order as
in the switch statement, which is a more natural order with
e.g. initialize coming first and release coming last).
PiperOrigin-RevId: 242891742
- Changed startDownloads/stopDownloads back to their previous behavior
of starting and stopping all downloads at the manager level.
- Made setManualStopReason methods for the new case of setting a manual
stop reason or some or all downloads.
- Added plumbing to specify an initial manual stop reason when adding a
new download, without also overwriting the manual stop reasons of all
other preexisting downloads. Using the value is left as a TODO pending
a bit of further cleanup that'll make it easier.
PiperOrigin-RevId: 242891688
- Remove completed downloads from progress notification.
- Treat restarting as a downloading, When there are both
remove and download tasks ongoing, we prefer to show a
download notification to a remove one. A restarting task
encapsulates is basically a (remove+download) task. Given
our preference, we should treat it as a download rather
than as a removal.
PiperOrigin-RevId: 242867228
Both manifest loads currently use the default retry delay although a
LoadErrorHandlingPolicy is provided to the MediaSource.
PiperOrigin-RevId: 242852672
- Remove NETWORK_TYPE_NOT_ROAMING and NETWORK_TYPE_METERED
because JobScheduler doesn't support them, and they're
probably not useful to many people (data when roaming is
normally enabled/disabled at the OS level, and restricting
to *only* metered networks seems niche)
- Convert network requirements proper flags
- Stop persisting requirements in DownloadIndex. The direction
we're headed to solve the manager start/stop problem is
going to involve state in DownloadManager determining whether
downloads actually start, and if we're doing that then it's
no worse to do it for this as well
PiperOrigin-RevId: 242713196
Robolectric calls messages posted to the main thread immediately inline. This
will change in the upcoming release and will break tests implicitly relying
on that behavior.
Update ConcatenatingMediaSourceTest to actually wait for the posted message.
PiperOrigin-RevId: 242631531
HashMap.values does not guarantee a stable order, but our tests
assert that the order is stable. It's probably a nice property
that the order is the same as that in which downloads are added,
so this change makes the order stable, with that order.
A future change will likely improve the way this works, by
changing the internal thread "downloads" variable to have type
ArrayList<Download>, at which point the internal thread can just
pass a read-only copy of its list to the main thread whenever a
state changes.
PiperOrigin-RevId: 242460725
- Fix ID being dropped when DownloadAction is serialized and
de-serialized as it's passed to DownloadService
- Properly set DownloadAction.id when building an action from
a DownloadState
- Make ID a required constructor argument. Else it's too easy
to not propagate it by accident.
PiperOrigin-RevId: 242457831
Remove MediaCodecSelector.DEFAULT_WITH_FALLBACK, as codec selectors
will need to be able to return a list of decoder infos even when not
using fallback in a later change. Instead signal that fallback should
be used via a renderer constructor.
Fallback is always disabled for audio.
PiperOrigin-RevId: 242454172
Adding a protected method for that allows to supply a customized
TrackOutputProvider to the ExtractorWrapper used by the ContainerMediaChunk
(e.g. for logging purposes).
The alternative would be to provide a TrackOutputProvider through the
ChunkSampleStream constructor, but the extra initialization taking place
in the ChunkSampleStream constructor would need to move somewhere else and
some methods of BaseMediaChunkOutput would need to move to the
TrackOutputProvider interface. This seems too much effort for niche
customization case.
PiperOrigin-RevId: 242448776
