Checking inputPosition == 0 isn't sufficient because the synchronization
at the top of read() may advance the input (i.e. in the case where there's
some garbage prior to the seek frame).
PiperOrigin-RevId: 261086901
This factory was only needed in the past when we didn't have
AnalyticsCollector.setPlayer. Code becomes easier to use without this factory.
PiperOrigin-RevId: 261081860
This new annotation declares everything as non-null by default and can be
used as a package annotation in package-info.java.
In this change the core lib offline package and the mediasession extension is
annotated that way as initial example usage.
PiperOrigin-RevId: 260894548
DefaultMediaClock has currently two non-ideal behaviours:
1. One part of checking if it should use the renderer clock is checking whether
the associated renderer finished reading its stream. This only makes sense
if the renderer isn't already reading ahead into the next period. This can
be solved by forwarding if we are reading ahead to the sync command.
2. When switching from stand-alone to renderer clock we assume they are
exactly at the same position. This is true in theory, but in practise there
may be small differences due to the different natures of these clocks. To
prevent jumping backwards in time, we can temporarily stop the stand-alone
clock and only switch once the renderer clock reached the same position.
PiperOrigin-RevId: 260690468
Both periods are rarely updated in the same iteration. If they are, advancing
the reading period first seems more logical and also more efficient as it may
avoid one extra doSomeWork iteration.
PiperOrigin-RevId: 260463735
When using speed adjustment it was possible for playback to get stuck at a
period transition when the channel count changed: SonicAudioProcessor would be
drained at the point of the period transition in preparation for creating a new
AudioTrack with the new channel count, but during draining the incorrect (new)
channel count was used to calculate the output buffer size for pending data from
Sonic. This meant that, for example, if the channel count changed from stereo to
mono we could have an output buffer size that stored an non-integer number of
audio frames, and in turn this would cause writing to the AudioTrack to get
stuck as the AudioTrack would prevent writing a partial audio frame.
Use Sonic's current channel count when draining output to fix the issue.
PiperOrigin-RevId: 260156541
We keep track of the last publicly known playing period to report it as part
of events happening after the period has been released.
In cases where a period briefly becomes the playing one and is released
immediately afterwards, we currently don't save it as the "last known playing
one". Improve that by saving an explicit reference.
Issue:#5407
PiperOrigin-RevId: 259737218
Creating a period in MaskingMediaSource may result in delayed event reporting
depending on when the actual period gets created. To avoid event reporting
inaccuracies, report the mediaPeriodCreated and mediaPeriodReleased events
directly.
Issue:#5407
PiperOrigin-RevId: 259737170
This changes the logic in the following ways:
- If no preferred language is matched, prefer better scores for the selected
audio language.
- If a preferred language is matched, always prefer the better match
irrespective of default or forced flags.
- If a preferred language score and the isForced flag is the same, prefer
tracks with a better selected audio language match.
PiperOrigin-RevId: 259707430
Some variables were defined although they are the default and other things
were set-up in a non-sensible way, e.g. asserting that audio is selected
although no audio renderer is available, or using unset duration for
everything.
PiperOrigin-RevId: 259532782
PlaybackInfo changes are one of the last ones not masked and reported in the same
way as all other changes.
The main change to support this is to also mask the parameters set in
DefaultAudioSink.
PiperOrigin-RevId: 258787744
1. Using the Locale on API<21 doesn't make any sense because it's a no-op
anyway. Slightly restructured the code to avoid that.
2. API<21 often reports languages with non-standard underscores instead of
dashes. Normalize that too.
3. Some invalid language tags on API>21 get normalized to "und". Use original
tag in such a case.
Issue:#6153
PiperOrigin-RevId: 258773463
2-letter codes (ISO 639-1) are the standard Android normalization and thus we
should prefer them to 3-letter codes (although both are technically allowed
according the BCP47).
This helps in two ways:
1. It simplifies app interaction with our normalized language codes as the
Locale class makes it easy to convert a 2-letter to a 3-letter code but
not the other way round.
2. It better normalizes codes on API<21 where we previously had issues with
language+country codes (see tests).
3. It allows us to normalize both ISO 639-2/T and ISO 639-2/B codes to the same
language.
PiperOrigin-RevId: 258729728
If we use the default start position, we currently resolve it immediately
even if we need to play an ad first, and later try to project forward again
if we believe that the default start position should be used.
This causes problems if a specific start position is set and the later
projection after the preroll ad shouldn't take place.
The problem is solved by keeping the content position as TIME_UNSET (= default
position) if an ad needs to be played first. The content after the ad can
then be resolved to its current default position if needed.
PiperOrigin-RevId: 258583948
These methods helps to indicate that a media source isn't used to create new
periods in the immediate term and thus limited resources can be released.
PiperOrigin-RevId: 258373069
It's easy to forget to forward methods when using basic wrapping. For example,
ExtractorMediaSource.addEventListener is currently a no-op because it's not
forwarded.
PiperOrigin-RevId: 257757556
This is a temporary workaround until we have migrated all MediaSources uses.
This change avoids having to migrate all uses of MediaSources immediately.
PiperOrigin-RevId: 257459138
- Remove manifest argument from callbacks of Player.EventListener and
SourceInfoRefreshListener. Instead make it accessible through
Player.getCurrentManifest() and Timeline.Window.manifest.
- Fix all MediaSource implementation to include the manifest in the
Timeline instead of passing it to the SourceInfoRefreshListener.
- Refactor ExoPlayerTestRunner, FakeTimeline, FakeMediaSource to
reflect these changes and make tests pass.
PiperOrigin-RevId: 257359662
Sending MESSAGE_PREPARE_SOURCE should happen last in the constructor.
It was previously happening before initialization finished (and in
particular before pendingMediaPeriods was instantiated).
Issue: #6146
PiperOrigin-RevId: 257158275
We currently handle most the control code logic after handling special
characters. This includes filtering out repeated control codes and checking
for the correct channel. As the special character sets are control codes as well,
these checks should happen before parsing the characters.
Issue:#6133
PiperOrigin-RevId: 256993672
- Explicitly specify HTTP_METHOD_POST (previously this was
implicit as a result of the body data being non-null)
- Use null when there's no body data (it's converted to
null inside of the DataSpec constructor anyway)
PiperOrigin-RevId: 256573384
Currently, we sometimes apply new playback parameters directly and sometimes
through the list of playbackParameterCheckpoints. Only when using the checkpoints,
we also reset the offset and corresponding position for speedup position
calculation. However, these offsets need to be changed in all cases to prevent
calculation errors during speedup calculation[1].
This change channels all playback parameters changes through the checkpoints to
ensure the offsets get updated accordingly. This fixes an issue introduced in
31911ca54a.
[1] - The speed up is calculated using the ratio of input and output bytes in
SonicAudioProcessor.scaleDurationForSpeedUp. Whenever we set new playback
parameters to the audio processor these two counts are reset. If we don't reset
the offsets too, the scaled timestamp can be a large value compared to the input
and output bytes causing massive inaccuracies (like the +20 seconds in the
linked issue).
Issue:#6117
PiperOrigin-RevId: 256533780
The masking logic for unprepared MediaSources is currently part of
ConcatanatingMediaSource. Moving it to its own class nicely separates the
code responsibilities and allows reuse.
PiperOrigin-RevId: 256360904
1. Only output video starting from a keyframe
2. When calculating the timestamp offset to adjust live streams to start
at t=0, use the timestamp of the first tag from which a sample is actually
output, rather than just the first audio/video tag. The test streams in
the referenced GitHub issue start with a video tag whose packet type is
AVC_PACKET_TYPE_SEQUENCE_HEADER (i.e. does not contain a sample) and whose
timestamp is set to 0 (i.e. isn't set). The timestamp is set correctly on
tags that from which a sample is actually output.
Issue: #6111
PiperOrigin-RevId: 256147747
The total window and period count, as well as the period offset for each holder
are not actually needed and can be removed.
Also added a TODO to remove two other variables if possible.
PiperOrigin-RevId: 255945584
We are currently queuing periods in a way such that the new start position
lines up with the end of the previous period (to ensure continuous playback).
However, if the start position of the new period is larger than the total of
all previously played period durations, we may end up with negative renderer
timestamps when seeking back to the beginning of this new period. Negative
timestamps should be avoided as most decoders have problems handling them
correctly.
This change forces a renderer reset if we detect such a seek to a negative
renderer time and also resets the renderer offset to 0 every time all
renderers are disabled, as this is the only time where we can savely change
the offset of an existing media period.
Also, if playback starts with an ad, we choose the content position as
renderer offset to prevent the whole issue from occurring for the seek-behind-
midroll case.
Issue:#6009
Issue:#5323
PiperOrigin-RevId: 253790054
In some edge cases the renderer position may be slightly ahead of the
buffered position and the total buffered duration is thus negative. We already
filter that in ExoPlayerImpl for the publicly accessible value. However, we
forward the unfiltered value to other components like the LoadControl, which
may be confusing.
Issue:#6015
PiperOrigin-RevId: 253780460
This permission has normal access right and can't be revoked by the user.
However, an app can choose to revoke it when using ExoPlayer, e.g. if
no network is required and the app doesn't want to list this permission.
Support this use case by gracefully catching the exception in the relevant
places.
Issue:#6019
PiperOrigin-RevId: 253759332
We currently report MediaCodec exceptions as unexpected exceptions instead of
as renderer error. All such exceptions are now wrapped in a new DecoderException
to allow adding more details to the exception.
PiperOrigin-RevId: 252054486
It's only thrown in an edge case on API level 20 and below. If it
is thrown it causes playback failure when playback could succeed,
by throwing up through configureCodec.
It seems better just to catch the exception and have the codec be
configured using the format's own width and height.
PiperOrigin-RevId: 251745539
We currently don't display the last frame because the seek time is behind the
last frame's timestamps and it's thus marked as decodeOnly.
This case can be detected by checking whether all data sent to the codec is
marked as decodeOnly at the time we read the end of stream signal. If so, we
can re-enable the last frame. This should work for almost all cases because the
end-of-stream signal is read in the same feedInputBuffer loop as the last
frame and we therefore haven't released the last frame buffer yet.
Issue:#2568
PiperOrigin-RevId: 251425870
Using parallel adaptation for Formats without bitrate information currently
causes an exception. Handle this gracefully and also cases where all formats
have the same bitrate.
Issue:#5971
PiperOrigin-RevId: 250682127
Setting the requested encoding in all cases ensures we receive the relevant
response headers indicating whether gzip was used. Doing that allows to
detect the content length in cases where gzip was requested, but the server
replied with uncompressed content.
PiperOrigin-RevId: 250660890
cache() opens all connections with unset length to avoid position errors.
This makes more data then needed to be downloading by the underlying
network stack.
This fix makes makes it open connections for only required length.
Issue:#5927
PiperOrigin-RevId: 250546175
"Write case, lock not available" was a bit confusing. When the
content is not cached and the lock is held, it's neither a read
or a write case. It's a "can't do anything" case. When blocking,
it may subsequently turn into either a read or a write.
PiperOrigin-RevId: 250530722
The former is deprecated and replaced by the latter in Mockito 2. However, there is a
functional difference: ArgumentMatchers will reject `null` and check the type
if the matcher specified a type (e.g. `any(Class)` or `anyInt()`). `any()` will
remain to accept anything.
PiperOrigin-RevId: 250458607
Removes the need for duplicate calls to SampleQueue#read when
implementing DecryptionResources acquisition in the MediaSources.
PiperOrigin-RevId: 250298175
The only known use case for contentTypePredicate is to catch
the case when a paywall web page is returned via a DataSource,
rather than the data that was being requested. These days streaming
providers should be using HTTPS, where this problem does not exist.
Devices have also gotten a lot better at showing their own
notifications when paywalls are detected, which largely mitigates
the need for the app to show a more optimal error message or
redirect the user to a browser.
It therefore makes sense to deprioritize this feature. In
particular by removing the arg from constructors, where nearly
all applications are probably passing null.
PiperOrigin-RevId: 249634594
This prevents further unexpected updates if the MediaSource happens to
finish its preparation at a later point.
Issue:#5915
PiperOrigin-RevId: 249439246
We are currently defaulting to targetSdk=1 as no targetSdk is specified. Only
tests which explicitly ask for another SDK use another test SDK. With the
versioned manifest, all tests run using the targetSDK by default.
PiperOrigin-RevId: 249060796
If a PlayerMessage throws an exception, it is currently not deleted from the
list of pending messages. This may be problematic as the list of pending
messages is kept when the player is retried without reset and the message is
sent again in such a case.
PiperOrigin-RevId: 247414494
Adding an explicit option to clear all downloads prevents repeated database
access in a loop when trying to delete all downloads.
However, we still create an arbitrary number of parallel Task threads for this
and seperate callbacks for each download.
PiperOrigin-RevId: 247234181
1. A content session after an ad has been played was not re-marked as active,
leading to new ad session being marked as active too early.
2. Switching from content to post-roll ended the content session because
the return value of getAdGroupTimeUs of C.TIME_END_OF_SOURCE was not
handled. Using the nextAdGroupIndex instead.
PiperOrigin-RevId: 246977327
As justification for why we should not have this type of logging,
it would scale up to about 13K LOC, 1800 Strings, and 36K (after
pro-guarding - in the case of the demo app) if we did it through
the whole code base*. It makes the code messier to read, and in
most cases doesn't add significant value.
Note: I left the Scheduler logging because it logs interactions
with some awkward library components outside of ExoPlayer, so is
perhaps a bit more justified.
* This is a bit unfair since realistically we wouldn't ever add
lots of logging into trivial classes. But I think it is fair
to say that the deltas would be non-negligible.
PiperOrigin-RevId: 246181421
- Removed DownloadInternal and its sometimes-out-of-sync
duplicate state
- Fixed downloads being in STOPPED rather than QUEUED state
when the manager is paused
- Fixed setMaxParallelDownloads to start/stop downloads if
necessary when the value changes
- Fixed isWaitingForRequirements
PiperOrigin-RevId: 246164845
They behave identically, and the old names are being removed.
Open-source note: The new methods are available in Truth as of version 0.44.
END_PUBLIC
More information:
go/issameas-lsc
Tested:
TAP --sample ran all affected tests and none failed
http://test/OCL:246024032:BASE:246042619:1556672975894:513e7746
PiperOrigin-RevId: 246101315
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
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
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
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 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
The position should be subtracted from the total content length
retrieved from the cache in this case, both for iteration and for
filling out counters.contentLength (for the latter, note not
doing it this way is inconsistent with what happens when dataSpec
length is set to a known value).
PiperOrigin-RevId: 242445034
It's a transient state whose only use is when passing a removed
download to onDownloadStateChanged. It's a bit strange to have it
as a proper state, since we end up asserting that it's an invalid
value in other places.
This change adds an explicit onDownloadRemoved, which allows
removal of the transient STATE_REMOVED, related assertions, and
uncertainty when dealing with an @State variable whether it's
necessary to handle it being STATE_REMOVED.
PiperOrigin-RevId: 242444128
This is the last cl of a series of cls that will convert DownloadManager
threading model as public methods post actions on an internal thread
which then do the work.
PiperOrigin-RevId: 242437229
The priority task manager only needs to listen to loading state changes and
is independent of the rest of DefaultLoadControl. This also fixes problems
where the player stops loading without consultin the LoadControl.
PiperOrigin-RevId: 242098374
This is the second cl of a series of cls that will convert DownloadManager
threading model as public methods post actions on an internal thread
which then do the work.
PiperOrigin-RevId: 241773765
Necessary for implementing scheme-independant resource management.
Example: A media source needs to have ownership of a crypto resource
while samples are in buffer (but not yet in the renderer).
PiperOrigin-RevId: 241698575
Most of our components that have Handler instances for calling
back to application code instantiate the Handler using Util.getLooper
in the constructor. This makes the two components that do
something else consistent with that model.
PiperOrigin-RevId: 241545575
If no track matches the preferred language or no preferred language is provided,
use the system Locale language as the next decision criterion.
PiperOrigin-RevId: 241322703
Custom factories currently need to copy most of the code in the
AdaptiveTrackSelection.Factory to make use of the same functionality.
Simplify this by allowing to overwrite the factory.
PiperOrigin-RevId: 240773271
This is the first of a series of cls that will convert DownloadManager
threading model as public methods post actions on an internal thread
which then do the work.
PiperOrigin-RevId: 240743400
The one functional change here is to require subclasses to implement getForegroundNotification. It seems easier and less error prone to
force developers to implement it than it does to document the cases
in which they need to override it (which is most cases).
PiperOrigin-RevId: 240566737
If enabled, DefaultTrackSelector returns multiple groups with more than one
track. AdaptiveTrackSelection then decides on the order in which the tracks
are changed such that the BandwidthProvider for each selection can figure out
the allocated bandwidth.
PiperOrigin-RevId: 240150206
It's currently very difficult to actually set a reason for track selection
triggered by a SelectionOverride. It would require creating a new custom
TrackSelection.Factory where the reason gets injected somehow before the
override is specified on the player.
Simplify this whole procedure by allowing to set the reason directly and
forward this reason to all fixed selections created based on this override.
PiperOrigin-RevId: 240114942
3 ("11") is the reserved code for fscod in AC3. The spec says that "If the
reserved code is indicated, the decoder should not attempt to decode audio and
should mute."
We currently throw an exception as we try to access an array with an invalid
index. Now ignoring the track instead by invalidating the format.
Issue:#5638
PiperOrigin-RevId: 240106255
This allows to distinguish between regional variants and scripts.
We still need to normalize the language code itself to make track selection
independent of the whether 2 or 3 letter codes are used.
PiperOrigin-RevId: 239783115
Any seek map with non-zero offsets breaks playback with ICY metadata as
the metadata is no longer read from the correct position.
Issue:#5658
PiperOrigin-RevId: 239605839
*** Reason for rollback ***
Trying to forward fix instead.
*** Original change description ***
Automated g4 rollback of changelist 237051112.
*** Original change description ***
Add SimpleCache deletion functionality
This is needed now that index data may be stored outside
of the cache directory.
***
***
PiperOrigin-RevId: 239429430
*** Original change description ***
Add SimpleCache deletion functionality
This is needed now that index data may be stored outside
of the cache directory.
***
PiperOrigin-RevId: 239294713
When an error occurs we call stopInternal, and this clears the MediaPeriodQueue,
which in turn releases media period holders and notifies that media periods have
been released. AnalyticsCollector updates its information about media periods
using the media period release events, which means that if we post the source
error after stopInternal posts its events we can't determine what media period
the source error corresponds to.
Move error notifications before calling stopInternal, so that
AnalyticsCollector's model of the media period queue contains the loading period
at the point when it handles the error.
For consistency also move the other (non-source) error notifications to match
the new ordering.
PiperOrigin-RevId: 238559324
This simplifies the DownloadHelper code in the demo app and is generally
useful for more specific updates with SelectionOverrides.
PiperOrigin-RevId: 238228276
This replaces the deprecated usages of RobolectricTestRunner and
RuntimeEnvironent and fully migrates the tests to androidx.
PiperOrigin-RevId: 238011667
We may currently throw if the load completes before we finished preparation.
Don't throw and instead check for this condition in maybeThrowPrepareError.
PiperOrigin-RevId: 237237000
These are thrown for non-IOException encountered during loading. Also, they
are thrown from an unexpected position and retrying is likely to fail anyway
because the Extractor is left in an unrecoverable state.
PiperOrigin-RevId: 237043948
SQLiteException is a runtime exception, which makes it easy to
forget to handle it. This change converts SQLiteExceptions into
a checked exception, which is then handled appropriately.
PiperOrigin-RevId: 237038793
Currently a flags-only DecoderInputBuffer may hold only the end-of-stream
flag. This change makes flags-only buffer read any kind of flag set in
the next sample. If no sample is available RESULT_NOTHING_READ is
returned.
PiperOrigin-RevId: 237027581
nalPrefix.readUnsignedIntToInt() will throw if the unsigned output doesn't fit
in an int. Before this change, in the error case we'd retry reading from after
the NAL prefix position. Throw a ParserException so that reading an obviously
invalid NAL prefix will be treated as a fatal exception by the default load
error handling policy.
PiperOrigin-RevId: 236839690
The release needs to post to the MediaSource thread and also needs to post
back to the DownloadHelper thread to prevent sending updates after release has
been called. The point where we release the downloadHelper also needs to
dismiss the dialog in case the creation has already been queued before the
release.
PiperOrigin-RevId: 236652309
This is more in line with "forgetting all previous state" as documented for
resetState=True. Also only apply the current position as initial seek position
in this case.
PiperOrigin-RevId: 236623630
We currently throw if a pending seek position was valid when the user issued
it on the app thread, but can't be resolved on the playback thread because the
timeline changed in the meantime. Throwing in this case seems wrong as the
user could not have known about the issue (and the seek position was actually
valid). Also, in other cases where the currently playing period is no longer
in the new timeline, we gracefully use a subsequent period or transition to
ENDED state instead of throwing. So it seems more consistent to transition to
ENDED state as well.
PiperOrigin-RevId: 236274862
The flag in ExoPlayer.prepare is documented as keeping the current window
index and window position. We are currently using the current period UID and
period position instead. This causes problems when the media source is changed
but the position is not reset.
Using the initial seek position instead ensures we actually use the window
index and position.
Issue:#5520
PiperOrigin-RevId: 236101024
Adding new error types may cause issues when listeners assume a fixed set of
error types and don't handle arbitrary defaults.
Fixing error handling in one case and improving documentation to make people
aware of the issue.
PiperOrigin-RevId: 236093265
While disabled the renderer does not have non-null stream formats. This means
that setting the operating rate could cause a NullPointerException if there was
a codec for reuse.
Check for being enabled/started before trying to set the operating rate. After
the renderer is enabled it should receive a new input format which will update
the operating rate as needed.
PiperOrigin-RevId: 235494384
If the DefaultAudioSink was reconfigured in a way that was compatible with the
previous configuration just after having been reset, we would try to drain audio
processors despite not having an AudioTrack. This could result in a
NullPointerException if speed adjustment was active.
Fix this behavior by only trying to drain audio processors if we actually have
an AudioTrack.
PiperOrigin-RevId: 235355466
- Expose constructor (package private for now, for tests only)
- Add some tests for cache initialization
- Add some TODOs for handling initialization failure
PiperOrigin-RevId: 235188386
*** Reason for rollback ***
Breaks ExoPlayer's gradle build
*** Original change description ***
Migrate Mockito Matchers.{hamcrestMethods} to MockitoHamcrest.{hamcrestMethods}
All methods accepting a hamcrest Matcher in org.mockito.Matchers have been changed
to only accept an ArgumentMatcher. The corresponding methods are now available on
MockitoHamcrest.
For more information see http://go/mockito-2-lsc
Tested:
TAP --sample for global presubmit queue
http://test/OCL:235033293:BASE:234998256:1550793421835:c2ccbbda
***
PiperOrigin-RevId: 235186705
All methods accepting a hamcrest Matcher in org.mockito.Matchers have been changed
to only accept an ArgumentMatcher. The corresponding methods are now available on
MockitoHamcrest.
For more information see http://go/mockito-2-lsc
Tested:
TAP --sample for global presubmit queue
http://test/OCL:235033293:BASE:234998256:1550793421835:c2ccbbda
PiperOrigin-RevId: 235153912
*** Reason for rollback ***
Reverting as this may break playback on other Amlogic devices and/or playback of non-interlaced content.
*** Original change description ***
Add max video size workaround for Amlogic decoder.
The Amlogic awesome decoder reduces the video size of interlaced videos by half
if the internal configuration isn't force reset with new maximum input size
values. The product of these new values must exceed 1920x1088 to force the
reset.
Issue:#5003
***
PiperOrigin-RevId: 234967314
- Use Cache UID for CacheContentIndex and CacheFileMetadataIndex. This
enables SD card swapping for a single device.
- I'm hopeful of finding a way to get the Cache UID to DefaultDownloadIndex
so we can do the same there.
PiperOrigin-RevId: 234662753
This is a temporary fix to prevent NullPointerException exceptions.
Though writing to cache will still fail if the cache folder isn't a real
folder.
There are a few thing we can try:
* The listing might be failing because the cache folder is just created.
We can wait and try again.
* If the cache folder is a regular file, we can try deleting and creating
a folder with the same name.
PiperOrigin-RevId: 234121925
Previously we would get a new AudioTrack and flush all audio processors if any
AudioProcessor needed to be flushed on reconfiguration. This was problematic for
the case of TrimmingAudioProcessor because it could become active or inactive
due to transitioning to a period with gapless metadata or without it (we don't
keep it active all the time because it is wasteful to populate its end buffer
for content that is not gapless).
This change handles the case where we don't need an AudioTrack but
AudioProcessors do need to be flushed. In this case we drain all the audio
processors when next handling data then switch to the new configuration.
This avoids truncation when period transitions change whether
TrimmingAudioProcessor is active but don't require a new AudioTrack, and is also
a step towards draining the AudioTrack when transitioning between periods if we
do need a new AudioTrack.
To do this, it needs to be possible to drain any pending output data from an
AudioProcessor after it's configured to a new format, so this change makes sure
AudioProcessors allow calling playToEndOfStream and getOutput after
reconfiguration and before flush.
PiperOrigin-RevId: 234033552
This cleanup is in preparation for draining audio processors on reconfiguration
to a format that doesn't require a new AudioTrack to be created.
PiperOrigin-RevId: 233990983
Stop encoding/decoding presentation time as part of the message.
What's actually in emsg boxes is a presentation time delta,
which is why it's only 32 bits, and hence why it doesn't handle
large absolute timestamps. We were using this field to hold
absolute timestamps only for the purpose of passing presentation
times from DashManifestParser.parseEvent back to the calling
method. After this change, we return Pair<Long, EventMessage>
instead.
Issue: #5490
PiperOrigin-RevId: 233561731
Switch from passing an ad UI ViewGroup to passing an object that can also
provide information about controls overlays.
Also switch to using a dedicated overlay for ads instead of the overlay frame
layout, which apps have easy access to.
PiperOrigin-RevId: 233393500
Supporting multiple overrides allows to select tracks from multiple groups, if
enabled. As more options are added, the creation of the dialog is moved to a
separate builder class.
PiperOrigin-RevId: 233366282
Imported from GitHub PR https://github.com/google/ExoPlayer/pull/5438
Plus the following changes:
- Only support profile 5 (handling other profiles requires
backward-compatibility changes in the renderer which are left for a later
change.)
- Only add KEY_PROFILE to the codec configuration MediaFormat for Dolby Vision.
- In MediaCodecUtil support all DV profiles that Android has constants for. This
includes ones that are "not supported for new applications". Since we don't
extract these profiles, this is currently only for the benefit of custom
extractors.
- Misc code style fixes and reordering for consistency.
Merge 37878b975c2bc082b0568e21cbe62bfcef97c10d into 67be9e7783
PiperOrigin-RevId: 233066799
Given the change to require setPlayer on AdsLoaders, it seems like a good
opportunity to clean up deprecated ads-related symbols.
PiperOrigin-RevId: 233020171
When SimpleCache uses a CacheFileMetadataIndex, it will be able to avoid
querying file.length() and renaming files, both of which are expensive
operations on some file systems.
PiperOrigin-RevId: 232664255
DefaultDownloadIndex is currently just forwarding all calls to its
inner class. getDownloadTable() handles initialization, but this
doesn't really seem different to having an initialization method. It
doesn't guarantee initialization happens, since a bad method
implementation could try and access downloadTable directly, just as
a bad method implementation could forget to call the initialization
method. Hence this change removes the indirection.
PiperOrigin-RevId: 232482228
This combines all the different listeners in ExoVideosPlayerV2 into one and
moves the PlaybackLogger class towards ExoPlayer's AnalyticsCollector with
the same purpose.
In the future this allows two things:
1. Gradually move LogginClient implementations to AnalyticsListener to
prevent custom event forwarding.
2. Using ExoPlayer's QoE extension (which is also an AnalyticsListener).
PiperOrigin-RevId: 232321182
When calling releaseSource(), all pending messages will be removed. That means
that all action-on-completion callbacks which are somewhere in flight are
just dropped without being called. This change adds code to keep track of the
current state of each callback to allow all of them being called when the
source is released.
Issue:#5464
PiperOrigin-RevId: 232312528
This change enables transitioning to/from different Storage
implementations, to allow experimentally enabling (and if
necessary, disabling) SQLiteStorage. All that's left to do
is the final wiring to turn it on
PiperOrigin-RevId: 232304458
If there is data after the last samples in the container, we may request
continue loading after the last samples have been read but before the load has
completed. In this situation the buffered position is returned as
Long.MAX_VALUE, which prevents continuing loading, yet the media period is not
treated as fully buffered because its buffered position is not
C.TIME_END_OF_SOURCE.
PiperOrigin-RevId: 231406964
We can keep the reading media period and continue playing if we haven't read
beyond the new duration. Otherwise, we can keep the period, but need to reset
the renderers as we already read too far.
PiperOrigin-RevId: 231406252
It better describes what the class does. More importantly, we've had
inconsistent class names since we added offline support, for which we
added ProgressiveDownloader ("ExtractorDownloader" doesn't make any
sense). We could really do with aligning the names for clarity.
(Sorry)
PiperOrigin-RevId: 231387268
This requires to prepare the media source and the periods in a small helper similar
to the metadata retriever. It also gets rid of the need to have abstract protected
methods to load the manifest, to extract the track groups and to convert to stream keys,
as this can now be handled by the media period.
PiperOrigin-RevId: 231385590
Converting a single track selection to stream keys is only possible if the output
is independent from other track selections being made.
This is not the case for DASH and HLS embedded track groups which should select the
already selected primary track if possible (and thus needs to know whether a primary
track group is selected).
Also, update the test method to take a period index.
PiperOrigin-RevId: 231385490
The way it is currently, it's very unclear that an operation on the
version table will correctly belong to a transaction in code such as
this, taken from DefaultDownloadIndex:
writableDatabase.beginTransaction();
try {
writableDatabase.execSQL(...);
versionTable.setVersion(...);
writableDatabase.setTransactionSuccessful();
} finally {
writableDatabase.endTransaction();
}
This change explicitly passes the database, to make it obvious that
the operation will really go into the same transaction:
writableDatabase.beginTransaction();
try {
writableDatabase.execSQL(....);
VersionTable.setVersion(writableDatabase, ...);
writableDatabase.setTransactionSuccessful();
} finally {
writableDatabase.endTransaction();
}
PiperOrigin-RevId: 231374933
Float output is only possible from API 21, but the high-res int
to float conversion path was checking for 32-bit PCM not float
output capability.
PiperOrigin-RevId: 231172495
