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
According to Cue's constructor (for bitmaps) documentation:
+ cuePositionAnchor does horizontal anchoring.
+ cueLineAnchor does vertical anchoring.
Usage is currently inverted.
Issue:#5633
PiperOrigin-RevId: 250253002
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
The SurfaceListener just sets the surface on the VideoComponent, but
SphericalSurfaceView already accesses the VideoComponent directly so it seems
simpler to update the surface directly.
PiperOrigin-RevId: 249242185
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
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
