*** 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
If an odd resolution is impossible in the specification itself, then we know
that the caller is passing invalid data. Round up on the assumption it's a
rounding error so that playback can proceed.
Issue: #6551
PiperOrigin-RevId: 275226813
If a surface was previously passed to the player then an output buffer
renderer was set, we would remove surface callbacks but not clear the
surface on renderers that accept MSG_SET_SURFACE.
PiperOrigin-RevId: 274532266
download calls through to CacheUtil#cache, which handles skipping already downloaded bytes.
It is useful for callers to know that ProgressiveDownloader has this behavior - otherwise, they might reimplement the logic themselves.
I hope this behavior is something that can be part of the public API :)
PiperOrigin-RevId: 274202995
This is a proof of concept for cleanup we should do for all of
our DataSource implementations as we move toward stabilizing
parts of the API.
- Move all XDataSourceFactory classes to be inner classes.
- Remove chained constructors for XDataSourceFactory classes. Keep
required args going through constructors. Use setters for the
rest.
- Not applicable in this case, but we probably want to deprecate
all but the no-arg method for instantiating eac XDataSource
instance (with the all-arg method kept but with the intention
of making it package private).
PiperOrigin-RevId: 274162076
- 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
Move reusable code from LibvpxVideoRenderer to SimpleDecoderVideoRenderer.
Pass outputBuffer to renderOutputBuffer method instead of keeping the reference in the renderer.
PiperOrigin-RevId: 272899549
We currently set it to shouldContinueLoading, which isn't correct if
shouldContinueLoading is set to false and we still have an ongoing load.
Change it to also be true if the media period is still loading.
PiperOrigin-RevId: 272823473
This method allows the player to figure out whether we still have an ongoing
load even if LoadControl.shouldContinueLoading returns false.
PiperOrigin-RevId: 272445577
This ensures a more consistent playback behavior no matter if an item is the
first playlist item or a later one. For example, each playlist item gets its
own onRenderedFirstFrame callback and other logic within the renderer that
force renders the first frame more quickly is also triggered.
PiperOrigin-RevId: 272434814
This doesn't change the current behaviour, just adds a clear error message
to the developer with instructions on how to avoid it.
Issue:#6470
PiperOrigin-RevId: 272405556
*** 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
Created the WakeLockManager for use in SimpleExoPlayer.
Added a setter in SimpleExoPlayer to adjust this functionality.
Issue:#5846
PiperOrigin-RevId: 272176998
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
Before: "Unexpected first three bytes of ID3 tag header: 6845556"
After: "Unexpected first three bytes of ID3 tag header: 0x687474"
PiperOrigin-RevId: 271949486
Adding this callback makes sense for completeness (we have similar callbacks
for all other playback state properties), and also to detect audio focus loss
while buffering which would currently trigger no callback because isPlaying
is still false.
Issue:#6203
PiperOrigin-RevId: 271347351
DrmSessionManagers may now be in released state, in which case they
may release their MediaDrm. In that case, it would be invalid to
forward method calls to the underlying MediaDrms. Users should
instead call these methods directly on the MediaDrm.
Issue:#4721
PiperOrigin-RevId: 270963393
Inline invocations of these methods, which still leaks the MediaDrms.
However, it will be fixed once the DefaultDrmSessionManager API is finalized
and ExoMediaDrm.Providers are introduced.
Issue:#4721
PiperOrigin-RevId: 270681467
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
This option allows to set the preferred text language and role flags based
on the user's accessiblity captioning settings.
Issue:#5749
PiperOrigin-RevId: 270233205
Allows streamlining the way we handle unsupported DRM. In general, either:
* The device does not support the CDM. For example, phones don't support
PlayReady.
* The device does not support the protection scheme. For example, API < 25
devices do not support AES-CBC.
Currently we handle both cases differently. A dummy ExoMediaDrm will allow
the existence of dummy DefaultDrmSessionManagers.
PiperOrigin-RevId: 269315687
Allows shared ownership of ExoMediaDrms. Shared ownership will
allow users to pre-create ExoMediaDrms in their apps, as opposed
to having the DrmSessionManager create the ExoMediaDrm.
Issue:#4721
PiperOrigin-RevId: 269305850
The player may suppress playback when waiting for audio focus even if the
state==Player.READY. There is currently no getter or callback to obtain this
piece of information for UI updates or analytics.
Also, it's a important derived state to know whether the playback position is
advancing. Add isPlaying and the corresponding callback to allow retrieving
this information more easily.
Issue:#6203
PiperOrigin-RevId: 268921721
We currently force render the first frame in all cases. However, when joining
video to an ongoing playback, there is no defined first frame and we should
rather drop frames if we are late until we caught up with the audio playback.
PiperOrigin-RevId: 268698093
When the queue is empty, we may still get multiple requests for a window
sequence number using the same periodUid. We should keep the initially
assigned number because no window change happened.
PiperOrigin-RevId: 268649009
The fLaC prefix is included in the initialization data output
from the MKV extractor, so this is highly likely ot be the
right thing to do.
Issue: #6397
PiperOrigin-RevId: 268244365
This allows to uniquely identify a window within a Timeline. The value is set
correctly for all Window instances, but is not used anywhere yet.
PiperOrigin-RevId: 267556516
We currently don't test if an ad needs to be played in case we are already
playing content.
This is to prevent recreating the current content period when
an ad is marked as skipped. We prefer playing until the designated ad group
position and appending another piece of content. This is less likely to cause
visible discontinuities in case the ad group position is at a key frame
boundary.
However, this means we currently miss updates that require us to play an ad
after a timeline update.
PiperOrigin-RevId: 267553459
Select a track with matching role flags even if someone specifies a preferred role flgs without providing a preferred language
Prefer track without captions or describing music and sound flag when no role flag preference is provided.
Removing this method requires custom MediaSource implementations to switch
to the new version. While this breaks the implmentation, it also avoids problems
with accidentely forwarding to the wrong method or with accidental stack
overflows when none of the two methods gets implemented.
It's unlikely any callers are affected because this is only the extended version
with the defaultProjectionPositionUs parameter that no caller except the
internal player will use.
PiperOrigin-RevId: 267323042
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
Sniffing is performed in ProgressiveMediaPeriod even if a single
extractor is provided. Skip it in that case to improve performances.
Issue:#6325
PiperOrigin-RevId: 266766373
The Javadoc for open() won't be read by anyone because it's an overridden method
of the interface and not called directly from application code.
Move doc to class documentation as this is a generic explanation about the
functionality of the class. Also added "all" to clarify that all the parameters
will be added and the order of preference just applies in case of key clashes.
PiperOrigin-RevId: 266753249
This is a no-op interim change to introduce key request error
handling customization. Following changes will allow users to
inject their own LoadErrorHandlingPolicy implementations.
Issue:#6334
PiperOrigin-RevId: 266344399
- Surface information provided by methods isHardwareAccelerated,
isSoftwareOnly and isVendor added in Android Q in MediaCodecInfo
class.
- Estimate this information based on the codec name for earlier API
levels.
Issue:#5839
PiperOrigin-RevId: 266334850
This generalizes our "does file still exist" check to also check
that the file is the expected length. If it's not, we don't trust
it. This avoids infinite recursion in CacheDataSource if a cache
file is truncated underneath the cache.
Issue: #6165
PiperOrigin-RevId: 265707928
Implementations of ForwardingTimeline may override any of the two variants of
this method. We need to ensure that the customized override is always called.
Add back the deprecated method and make it final to forward to the
non-deprecated method in all cases for ForwardingTimelines.
PiperOrigin-RevId: 265419830
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 implementation can't work properly unless these methods are called by
subclasses, so annotate them to require calling the super implementation when
overriding.
PiperOrigin-RevId: 265017433
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
Currently the value of FLAG_ALLOW_CACHE_FRAGMENTATION is defined as "1 << 4" but commented as "8". Either the value of FLAG_ALLOW_CACHE_FRAGMENTATION should be "1 << 3", or the comment should be 16. Here I am modifying the comment since it does not affect any current behavior.
PiperOrigin-RevId: 265011839
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
Extract supplemental data from block additions in WebM/Matroska.
Allow storing supplemental data alongside samples in the SampleQueue and write
it as a separate field in DecoderInputBuffers.
Handle supplemental data in the VP9 extension by propagating it to the output
buffer.
Handle supplemental data for HDR10+ in MediaCodecVideoRenderer by passing it to
MediaCodec.setParameters, if supported by the component.
PiperOrigin-RevId: 264582805
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
Most users are likely to be only interested in the playlist items. So put the
Window definition first and explicitly mention that this is a playlist
item.
PiperOrigin-RevId: 263764515
The current ExoPlayerFactory is growing too big and usage becomes increasingly
complicated because it's not possible to set individual components without
specifying many other defaults.
Adding new builder classes makes building easier and more future-proof.
PiperOrigin-RevId: 263339078
entries are used in .equals(), so it's good to have them printed in toString() too (for test failures) and it makes logging easier too.
PiperOrigin-RevId: 263335503
The current max video buffer is 13MB which is too small for high quality
streams and doesn't allow the DefaultLoadControl to buffer up to its default
max buffer time of 50 seconds.
Also move util method and constants only used by DefaultLoadControl into this
class.
PiperOrigin-RevId: 263328088
I think we need to start clearing the holder as part of the
DRM rework. When we do this, it'll only be valid to read
from the holder immediately after it's been populated.
PiperOrigin-RevId: 262362725
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
This also decouples EventMessageEncoder's serialization schema from the emesg spec (it happens to still match the emsg-v0 spec, but this is no longer required).
PiperOrigin-RevId: 261877918
If we keep streams in chunk sources after selecting new tracks, we also keep
a reference to a stale disabled TrackSelection object. Fix this by updating
the TrackSelection object when keeping the stream. The static part of the
selection (i.e. the subset of selected tracks) stays the same in all cases.
Issue:#6256
PiperOrigin-RevId: 261696082
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
Android considers ALAC initialization data to consider of the magic
cookie only, where-as FFmpeg requires a full atom. Standardize around
the Android definition, since it makes more sense (the magic cookie
being contained within an atom is container specific, where-as the
decoder shouldn't care what container the media stream is carried in)
Issue: #5938
PiperOrigin-RevId: 261124155
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
