This is a nice-regardless improvement to SampleQueue, which will
likely to used to fix the referenced issue. It makes it possible
for SampleQueue subclasses to support dynamic changes to format
adjustment in a non-hacky way.
Issue: #6903
PiperOrigin-RevId: 292314720
We currently only keep the requested next content start position while
we are playing ads. However, we should also keep at least before a content
period is fully prepared to not loose the information about the user intent.
PiperOrigin-RevId: 291705752
There are existing bugs that need this flag to know whether the
current information in the window is still a placeholder or can
already be relied on for further calculation.
This flag will probably only ever be set in DummyTimeline, so it's
not added to the window.set method to avoid updating all clients.
Issue:#5924
PiperOrigin-RevId: 291705637
It could either live in .util or .extractor, but since it's not needed
outside the extractor package in core (and the FLAC extension), and
FlacStreamMetadataTest uses a FLAC asset, it seems preferable to move it
into the extractor package.
PiperOrigin-RevId: 291372032
Using @Test(expected=...) is discouraged, since the test will pass if
any statement in the test method throws the expected exception.
PiperOrigin-RevId: 291338224
The only remaining use is to provide the initial position for the first media
period in the queue. At this point, the value is always equivalent to
PlaybackInfo.positionUs because they are set together to the same value in
PlaybackInfo.copyWithNewPosition.
PiperOrigin-RevId: 290749294
I needed to use Cue.Builder instead of just SpannableStringBuilder for
the regionOutput values, so I could attach the vertical info where
appropriate (since this is a property of the Cue, not a span).
PiperOrigin-RevId: 290709294
If an exception is thrown between updating the timeline and updating
the position in playbackInfo, the state may be inconsistent.
Exceptions are expected to be thrown while updating the player state
and we should handle such cases in a consistent way.
Similar to how we handle the same situation in seekToInternal,
the state is updated in a final block such that it gets updated to the
latest state even if an error occurs. Moving both the timeline and
position update together also ensures they always stay consistent.
PiperOrigin-RevId: 290624020
This restructure moves all the position resolving code to a static method and
removes the dependency of the MediaPeriodQueue on having an up-to-date timeline.
Both steps allow simplified reasoning about the code as the static method can't change
the state of the player, and there is no risk the queue can use the wrong timeline.
These propoerties allow to fix a bug causing inconsistent states in a follow-up step.
PiperOrigin-RevId: 290616395
This makes MPEG audio utilities similar to utilities we have for WAV,
AC-3 etc., and moves them out of the extractor package so that an
extractor module can be split out without needing to have a class in the
extractor package in the common library.
PiperOrigin-RevId: 290595089
*** Original commit ***
Rollback of ff89170b00
*** Original commit ***
Fix some logic in AnalyticsCollector.
All events issued from ExoPlayerImpl (i.e. Player.EventListener events) currently
try to use the media period data from the playing media period as set in the
playback thread queue. This is only correct as long as there no pending masking
operations in ExoPlayerImpl. That's why we currently disable this whenever the timeline
is...
***
PiperOrigin-RevId: 290593700
*** Original commit ***
Fix some logic in AnalyticsCollector.
All events issued from ExoPlayerImpl (i.e. Player.EventListener events) currently
try to use the media period data from the playing media period as set in the
playback thread queue. This is only correct as long as there no pending masking
operations in ExoPlayerImpl. That's why we currently disable this whenever the timeline
is empty or a seek is pending. Since adding all the playlist API methods to the player,
this is no longer the right choice. Moreover,...
***
PiperOrigin-RevId: 290312118
Currently both are updated by separate setters. If an exception is thrown between
the two setters, the state may not be consistent.
Avoid this problem by always setting them together.
PiperOrigin-RevId: 290293600
All events issued from ExoPlayerImpl (i.e. Player.EventListener events) currently
try to use the media period data from the playing media period as set in the
playback thread queue. This is only correct as long as there no pending masking
operations in ExoPlayerImpl. That's why we currently disable this whenever the timeline
is empty or a seek is pending. Since adding all the playlist API methods to the player,
this is no longer the right choice. Moreover, we don't have a definite API that tells
AnalyticsCollector when a playlist API call has been handled (and we don't want to
have one).
We can fix this by always using the current Player position information as the source
of truth (instead of the media period queue). This is definitely more correct and also
works while a masking operation is pending. To fill in the additional information from
the media period queue, we can look up a matching media period. This may not be the
first one in the list if an operation is pending.
The new methods are similar to the previous tryResolveWindowIndex method, but:
1. They are always used (i.e. the current Player state is the main source of truth)
2. They also check the correct ad playback state, that was just ignored previously.
PiperOrigin-RevId: 290284916
Currently seeks are basically ignored. However, it's more realistic to re-queue the
single sample if the seek is to position 0.
PiperOrigin-RevId: 290273564
*** Original commit ***
Rollback of d48dc4c159
*** Original commit ***
Move getting-stuck-prevention into DefaultLoadControl.
We recently added code that prevents getting stuck if the buffer is low and
the LoadControl refuses to continue loading (b84bde0252).
Move this logic into DefaultLoadControl to keep the workaround, and also apply the
maximum buffer size check in bytes if enabled. ExoPlayerImplInternal will now
throw if a...
***
PiperOrigin-RevId: 290273295
This method has two use cases:
1. Seeking. Calls are immediately preceded by a call to rewind(), and
the returned value isn't important unless it's ADVANCED_FAILED (i.e.
the caller is only interested in success and failure).
2. Advancing. The return value is important unless it's ADVANCED_FAILED,
in which case the caller wants to treat it as 0.
This change creates separate methods for each use case. The new seekTo
methods automatically rewind and return a boolean. The updated advanceTo
method returns 0 directly in cases where ADVANCED_FAILED was returned.
Arguments that were always hard-coded to true by callers have also been
removed.
This change is a step toward one possible solution for #6155. How we'll
solve that issue is still up for discussion, but this change seems like
one we should make regardless!
Issue: #6155
PiperOrigin-RevId: 290053743
Currently the following sequence of events happens at automatic period transitions:
1. Update queue (=release old playing period)
2. Disable unused renderers
3. Enable newly needed renderers
This order requires difficult to follow workarounds in AnalyticsCollector for all
events related to step 2 (disable renderers). The current media period has already
been advanced so can't be used. The current workaround saves the last known playing
media period that was published as part of a PlaybackInfo update in ExoPlayerImpl.
This works in most cases, but is inherently wrong because the published state in
ExoPlayerImpl may be completely unrelated to the updates happening on the playback
thread (e.g. if many other operations are pending).
Simplify and fix this problem by changing the order of the events above:
1. Disable unused renderers.
2. Update queue
3. Enable newly needed renderers.
This way the current playing media period can be used for both renderer disable
and renderer enable events, thus it's correct in all cases and the workaround
in AnalyticsCollector can be removed.
PiperOrigin-RevId: 290037225
We currently have a currentMediaPeriodId and an activeSessionId that are more
or less tracking the same thing unless the current media period isn't "active" yet.
Simplify this logic by using a single currentSessionId field and the respective
isActive flag of this session. Also move all session creation and activation code in
the same method to make it easier to reason about the code.
This change also fixes a subtle bug where events after a seek to a new window
are not ignored as they should.
PiperOrigin-RevId: 289432181
These make the interesting bits of each assertion harder to follow imo.
Also remove all the assertWithMessage() calls at the same time, Olly
convinced me these are rarely useful since you can click from the stack
trace to the failing line in the IDE.
PiperOrigin-RevId: 288470704
- Simulate IO exceptions in the test using FlacBinarySearchSeeker for
seeking in FlacExtractorTests. This makes the test slower but covers
more test cases.
PiperOrigin-RevId: 288285057
There's currently no rendering support for ruby text in SubtitleView
or SubtitlePainter, but this does have a visible impact with the
current implementation by stripping the ruby text from Cue.text
meaning it doesn't show up at all under the 'naive' rendering.
This is an improvement over the current behaviour of including
the ruby text in-line with the base text (no rubies is better than
wrongly rendered rubies).
PiperOrigin-RevId: 288280416
This typo was introduced in ddb70d96ad
when migrating a static method with parameter `durationUs` to an
instance method where the correct field to use was `blockDurationUs`
(but `durationUs` also exists).
The test that catches this was only added in 45013ece1e (and
therefore configured with the wrong expected output data).
issue:#6833
PiperOrigin-RevId: 288274197
I decided the flags bit was a bit unclear so I played around with this
It's also needed for more 'complex' assertions like colors - I didn't
want to just chuck in a fourth int parameter to create:
hasForegroundColorSpan(int start, int end, int flags, int color)
PiperOrigin-RevId: 287989424
Relying on the precedence of spans seems risky - I can't find it
defined anywhere. It might have changed in Android 6.0?
https://stackoverflow.com/q/34631851
PiperOrigin-RevId: 287989365
-- Optimize Mp4Extractor for AC-4
-- Optimize FragmentedMp4Extractor for AC-4
-- Add test case for AC-4 in MP4
-- Add test case for AC-4 in Fragmented MP4
An experiment with this algorithm didn't show positive results. We can
therefore keep the simpler default algorithm.
Startblock:
<unknown commit> is submitted
PiperOrigin-RevId: 287807538
The Download constructor considers it invalid to have a failure
reason if the download isn't in the failed state. Unfortunately,
calling DefaultDownloadIndex.removeAllDownloads when there's a
failed download will change the state without clearing the reason.
If the downloads are then read back from the DefaultDownloadIndex
we end up violating the Download constructor assertion.
This change clears the failed reason for any existing rows in the
invalid state, and also fixes the root cause that allows invalid
rows to enter the table in the first place.
Issue: #6785
PiperOrigin-RevId: 286576242
This class is only used to hold temporary data while we parse the
settings and text, so we don't need it outside the Parser class.
Also remove all state from WebvttCueParser - this increases
the number of allocations, but there are already many
and subtitles generally aren't very frequent (compared to
e.g. video frames).
PiperOrigin-RevId: 286200002
*** Original commit ***
Move getting-stuck-prevention into DefaultLoadControl.
We recently added code that prevents getting stuck if the buffer is low and
the LoadControl refuses to continue loading (b84bde0252).
Move this logic into DefaultLoadControl to keep the workaround, and also apply the
maximum buffer size check in bytes if enabled. ExoPlayerImplInternal will now
throw if a LoadControl lets playback get stuck. This includes the case where
DefaultLoadControl reaches its maximum buffer size and not even a mim...
***
PiperOrigin-RevId: 286071115
We recently added code that prevents getting stuck if the buffer is low and
the LoadControl refuses to continue loading (b84bde0252).
Move this logic into DefaultLoadControl to keep the workaround, and also apply the
maximum buffer size check in bytes if enabled. ExoPlayerImplInternal will now
throw if a LoadControl lets playback get stuck. This includes the case where
DefaultLoadControl reaches its maximum buffer size and not even a mimimal buffer
duration.
PiperOrigin-RevId: 285979989
This offset allows to improve the calculated live offset because it
can take known client-server time offsets into account.
PiperOrigin-RevId: 285970738
I want to add fields related to vertical text support, and neither
adding another constructor nor updating all call-sites of existing
constructors seemed like attractive propositions.
PiperOrigin-RevId: 285956024
MultiLockAsyncMediaCodecAdapter is an implementation of the
MediaCodecAdapter that uses multiple locks to synchronize access to its
data compared to the single-lock approach used in
DedicatedThreadAsyncMediaCodecAdapter.
PiperOrigin-RevId: 285944702
- Make extractor output samples that are uniformly distributed
with respect to time, with a target of ~10 samples per second.
The old approach could in theory put every frame into its own
sample, which would be very inefficient downstream because we'd
need to pass them individually to MediaCodec. It could also put
data corresponding to a long duration of time into a single
sample (e.g. if the sample rate of the content is low), which
is bad downstream because we decide whether to set the decodeOnly
flag on a per sample basis. More generally, the new approach
is more predictable :).
- Stop using the WavSeekMap to get sample timestamps, and instead
calculate them directly from the number of frames output. It's
more obviously correct, particularly for data formats like IMA
ADPCM where we'll need to adjust the data prior to output.
PiperOrigin-RevId: 285750010
In MatroskaExtractor, if the last cue time exceeds the duration
specified in the header, then we end up generating a negative
duration chunk as the last item in the SeekMap. We should probably
not do this, so drop it instead.
Note: Matroska does have a CueDuration element, but it's not used
in the one problematic file I've found.
PiperOrigin-RevId: 285738418
Also change IcyInfo.rawMetatadata from String to byte[]
ICY doesn't specify the character encoding, and there are streams
not using UTF-8 (issue:#6753). It seems the default of at least one
server is ISO-8859-1 so let's support that as a fallback:
https://github.com/savonet/liquidsoap/issues/411#issuecomment-288759200
Also update IcyDecoder to skip strings it doesn't recognise at all
instead of decoding invalid characters.
The feed from issue:#6753 now decodes accents correctly:
EventLogger: ICY: title="D Pai - Le temps de la rentrée", url="null"
PiperOrigin-RevId: 285388522
We previously used Locale.fromLanguageTag and then toLanguageTag to automatically
filter out invalid tags and to replace deprecated tags. However, this only works
for API 21+.
This change does no longer rely on the platform methods and instead:
1. Keeps invalid tags as they are. This may help if developers rely on
non-spec-complaint language tags (for example, #6681).
2. Adds a list of deprcated tags and their modern replacements to our code
3. Normalizes some short codes that have been superseded by macrolanguage codes by
their macrolanguage equivalent.
Issue:#6681
PiperOrigin-RevId: 285384841
This has been broken since
c3d6be3afd
and broken for ICY (where I noticed the problem) since
5695bae9d8.
ICY symptom is that we see no repeated metadata, because the
Icy-MetaData:1 header doesn't make it to the server so we never get back
icy-metaint.
PiperOrigin-RevId: 285379234
Retrieve the sample number in the extractor instead of passing a holder
to FlacBinarySearchSeeker. This change makes the code easier to
understand and is required to implement the seeking from the seek table.
PiperOrigin-RevId: 285241862
This avoids needing to jump through type paremeter hoops to create a
sub-classable Cue.Builder.
Cue should have a standard set of fields, because it will be
consumed by renderers that don't know what type it is. The
existing subclass fields are only used inside their respective
packages, so can be part of a wrapper object instead.
This lays the groundwork for converting Cue's multiple constructors
into a Builder pattern.
PiperOrigin-RevId: 284992135
This makes the format metadata null (instead of an empty Metadata
object) when it is not provided, and is therefore consistent with the
other extractors behavior.
PiperOrigin-RevId: 284171148
The capture frame rate is currently available both via Format.metadata
and decoded in Format.frameRate. As the container Format.frameRate may
be useful to apps, only store the capture frame rate in metadata (apps
will need to decode it but can now access the container frame rate too).
PiperOrigin-RevId: 284165711
Calls to new Handler() without arguments are deprecated as of the latest Android
version. Replace them by a Util.createHandler call similar to the ones we
already have.
PiperOrigin-RevId: 283532891
Fixes issue:#6700
sample_cbs_truncated.adts test file produced using
`$ split -b 31795 sample_truncated.adts` to remove the last 10 bytes
PiperOrigin-RevId: 283530136
If LoadControl.shouldContinueLoading returns false and the renderers are not
ready for playback using the already buffered data, playback is stuck.
To prevent this situation, we always continue loading if the buffer is almost
empty. We already have a similar workaround for when
LoadControl.shouldStartPlayback returns false even if loading stopped.
Having both workarounds allows playback to continue even if the LoadControl
tries to prevent loading and playing all the time.
PiperOrigin-RevId: 283516750
This simplifies the contract of configure and is in preparation for
fixing a bug where more input can't be queued when draining audio
processors for a configuration change.
Issue: #6601
PiperOrigin-RevId: 282514367
- Move property to DrmSession; it feels like a more natural place
for it to go (and provides greater flexibility).
- Change flags to a boolean.
PiperOrigin-RevId: 281758729
Also remove the "do we really need to do this" comment for AAC.
Parsing from codec specific data is likely to be more robust, so
I think we should continue to do it for formats where we've seen
this problem.
Issue: #6648
PiperOrigin-RevId: 280575466
To trigger receiving the broadcast it's necessary to idle() the shadow
main looper, which has to be done from the test thread. Therefore this
change removes the send broadcast action and instead sends the broadcast
from the test thread.
PiperOrigin-RevId: 279660935
This means multiple failures are all logged, instead of the test
stopping when the first assertion fails. Makes tests like this with
lots of independent assertions much easier to work with.
I limited the expect to a single assertCues() call, otherwise
the error message gets very long and is hard to read, but I
still think this is an improvement.
PiperOrigin-RevId: 277523300
Cue's UNSET and null values should be used when the source data
doesn't specify *and* the spec doesn't provide a clear default.
In the WebVTT case, the defaults are clear, so we use them
explicitly.
PiperOrigin-RevId: 277522899
Also remove it from all tests, these aren't covered by the null-checker
Covered by the following package-info.java files:
- j/c/g/a/exoplayer2/ext/mediasession/package-info.java
- j/c/g/a/exoplayer2/package-info.java
- j/c/g/a/exoplayer2/offline/package-info.java
- j/c/g/a/exoplayer2/video/package-info.java
- j/c/g/a/exoplayer2/ui/package-info.java
PiperOrigin-RevId: 277038916
With lots of int comparisons close together, this makes the error
messages much clearer and saves having to manually match up line
numbers.
Also make every @Test just throw Exception
PiperOrigin-RevId: 276079806
*** Original commit ***
Rollback of 4ad4e3e4fc
*** Original commit ***
Rollback of 3b22db33ba
*** Original commit ***
add top-level playlist API to ExoPlayer
Public design doc:
https://docs.google.com/document/d/11...
***
PiperOrigin-RevId: 275813737
ConditionVariable.block(timeout) doesn't work in Robolectric, because it
relies on the system clock which doesn't advance.
PiperOrigin-RevId: 275798281
- Verifies that playWhenReady doesn't become true if audio focus
is denied.
- Also verifies there's no suppression reason in this case, because
the denial is permanent rather than temporary.
PiperOrigin-RevId: 274141099
This method allows the player to figure out whether we still have an ongoing
load even if LoadControl.shouldContinueLoading returns false.
PiperOrigin-RevId: 272445577
*** Original commit ***
Modify EventMessageDecoder to return null if decoding fails (currently throws exceptions)
This matches the documentation on MetadataDecoder.decode:
"@return The decoded metadata object, or null if the metadata could not be decoded."
***
PiperOrigin-RevId: 272405287
This flag is currently merged into Window.isDynamic, which isn't always true
because
1. A window can be dynamic for other reasons (e.g. when the duration is still
missing).
2. A live stream can be become non-dynamic when it ends.
Issue:#2668
Issue:#5973
PiperOrigin-RevId: 271999378
Remove the flag DataSpec.FLAG_ALLOW_ICY_METADATA. Instead, set the
header IcyHeaders.REQUEST_HEADER_ENABLE_METADATA_NAME in the DataSpec
httpRequestHeaders.
BUG:134034248
PiperOrigin-RevId: 270662676
With the internal playlist some new situation may happen that were not possible before:
- handlePlaylistInfoRefreshed in EPII called in IDLE state
- handlePlaylistInfoRefreshed in EPII called in ENDED state with an empty playlist
- seeks in ENDED state with an empty playlist
PiperOrigin-RevId: 270316681
Include Dataspec.httpRequestHeaders in CronetDataSource,
and OkHttpDataSource. Updated documentation of
HttpDataSource.open() to suggest that it should set request
headers (in decreasing priority) from (1) the passed DataSpec,
(2) parameters set with setRequestProperty() and (3) default
parameters set in the HttpDataSource.Factory. No mechanism
has been put in place to enforce this.
PiperOrigin-RevId: 266895574
The last selection criteria is the audio bitrate to prefer higher-quality
streams. We shouldn't apply this criterium though if the languages of the
tracks are different.
Issue:#6335
PiperOrigin-RevId: 265064756
The error is closely related to the playback state IDLE and should be updated
in sync with the state to prevent unexpected event ordering and/or keeping the
error after re-preparation.
Issue:#5407
PiperOrigin-RevId: 265014630
The app is able to pass a more specialized array type, so the Arrays.copyOf call
produces an array into which it's not valid to store arbitrary AudioProcessors.
Create a new array and copy into it to avoid this problem.
PiperOrigin-RevId: 264779164
There is no point in having this parameter as the tag should always be a single
immutable object instantiated at the time the Timeline is created or earlier.
So there is no preformance benefit and it's error-prone in case people
forget to set setTag=true.
PiperOrigin-RevId: 264117041
This solves various issues around event association for buffering and
error throwing around period discontinuities.
The main changes are:
- Logic around being "ready" at the end of a period no longer checks if the
next period is prepared.
- Advancing the playing period no longer checks if the next one is prepared.
- Prepare errors are always thrown for the playing period.
This changes the semantics and assumptions about the "playing" period:
1. The playing period can no longer assumed to be prepared.
2. We no longer have a case where the queue is non-empty and the playing or
reading periods are unassigned (=null).
Most other code changes ensure that these changed assumptions are handled.
Issue:#5407
PiperOrigin-RevId: 263776304
This matches the documentation on MetadataDecoder.decode:
"@return The decoded metadata object, or null if the metadata could not be decoded."
PiperOrigin-RevId: 263767144
We're no longer tied to the emsg spec, so we can skip unused fields
and assume ms for duration.
Also remove @Nullable annotation from EventMessageEncoder#encode, it
seems the current implementation never returns null
PiperOrigin-RevId: 262135009
We already allow mixed mime type and mixed sample rate adaptation on request,
so for completeness, we can also allow mixed channel count adaptation.
Issue:#6257
PiperOrigin-RevId: 261930046
We currently keep the sequence number if we don't reset the position. However,
the sequence number should be kept if we don't reset the state. Otherwise
re-prepare with position reset is counted as new playback although it's still
the same.
PiperOrigin-RevId: 261644924
- When in STATE_SEEK with targetGranule==0, seeking would exit
without checking that the input was positioned at the correct
place.
- Seeking could fail due to trying to read beyond the end of the
stream.
- Seeking was not robust against IO errors during the skip phase
that occurs after the binary search has sufficiently converged.
PiperOrigin-RevId: 261317035
Two tests have very low propability flakiness (1:1000) due to not waiting for
a seek in one case and the chance of already being ended in another case.
Fix these and also adjust wrong comments about state changes.
PiperOrigin-RevId: 261309976
These values can easily default to the empty track group and the empty
selection. As a result we can remove restrictions about not calling
holder.getTrackGroups before the period finished preparation.
PiperOrigin-RevId: 261280927
A previous change switched to calculation of the bitrate based on the
first MPEG audio header in the stream. This had the effect of fixing
seeking to be consistent with playing from the start for streams where
every frame has the same padding value, but broke streams where the
encoder (correctly) modifies the padding value to match the declared
bitrate in the header.
Issue: #6238
PiperOrigin-RevId: 261163904
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
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
