ExoCastMessage contains all player management messages that the sender app can
send to the receiver app. ExoCastMessages can be serialized as JSON strings.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218846977
- Only use bitrate when comparing two tracks if their bitrates are
actually different.
- For audio, prefer to use bitrate over selection flags.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218660886
- Improve variable naming
- In the edge case that bytes are transferred in a sample that
has 0 elapsed time, carry the bytes forward into the next
sample. If we don't do this then the estimate will be calculated
as though those bytes were never transferred. In practice I
suspect this very rarely occurs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218551208
If EventDispatcher.removeListener is called to remove a listener,
and if the call is made from the same thread that said listener
handles events on, then it should be guaranteed that the listener
will not be subsequently invoked on that thread.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218331427
In ConcatenatingMediaSource, the source may be removed before it started
preparing (this may happen if lazyPreparation=true). In this case, we
shouldn't call releaseSource as the preparation didn't start.
Issue:#4986
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218141658
There are multiple subtle issues with the current implementation:
1. setOperatingRate can cause a codec initialization even if the
renderer is disabled. This is not supposed to happen.
2. If the codec is released whilst the renderer is disabled, the
renderer can instantiate a new codec using the old format when
it's enabled again, only to immediately have to reconfigure or
release it if the actual format to be played is different.
3. Codec reuse does not take into account renderer configuration.
The specific case where this is problematic is if the video
renderer is re-enabled with a different tunneling session id.
The reused codec is then not configured correctly.
Also moved availableCodecInfos reset into releaseCodec for sanity.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217924592
This is a no-op change as the respective values are not used so far but
the change makes the current state cleaner and is less error-prone.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217892421
- Added ability to override the DefaultBandwidthMeter network type.
- These methods currently only work properly if called before the
meter is used, but the plan is for them to be handled in the same
way as internally detected network changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217887019
This method only ensured backward compatibility while the new version was not
public yet. Now ExoPlayer 2.9.0. is public, this workaround can be removed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217881691
I don't think there's any particular reason for releasing
dummySurface when we release the codec. It seems to make
more sense to decouple the two, and treat a dummySurface as
a resource that should be released on reset.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217711788
setSurface only sets the output surface on the codec if the
renderer is enabled or started. This was fine in the past
because the codec was always null in other states, however
the recent codec reuse work means this is no longer the case.
The output surface should always be set if the codec is
non-null. If setting the surface requires releasing the codec
instance, we should only instantiate the new instance if
enabled or started. This is in line with what onDisabled does
if flushing requires releasing the codec
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217676434
Just not doing it seems simplier and more obviously correct
than suppressing the warnings in our proguard file.
Issue: #4890
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217675527
1. Remove option to pass null context to Util.getNetworkType. IMO it's
clearer for the caller to just not call the method in this case.
2. Stop using deprecated DefaultBandwidthMeter.Builder constructor in
all but one place.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217147091
The assertion was so weak it probably wouldn't detect genuine
misuse of the DefaultAllocator API, so it seems fine just to
remove it.
We don't really know what happens when the player is allowed to
continue on the affected devices, but hopefully it either "just
works" or fails in a more graceful way.
Issue: #4532
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217113060
Robustness fix to make sure we ignore tags with known names, but
which are nested inside of unknown tags. For example we don't want
to parse the third period in:
<Period>...</Period>
<Period>...</Period>
<CustomTag>
<Period>...</Period>
</CustomTag>
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217101630
For decoder reuse, we want disable() to flush the decoder. However,
if the flush needs to release the decoder for some reason, it seems
non-ideal to immediately re-initialize it. Re-initialization can
also throw ExoPlaybackException, which we don't want for disabling.
This change allows a variant of flush that wont re-initialize the
decoder if it has to be released, which will be used from disable().
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=216834862
reloading frmo snapshots. b/117347850. This is a no-op change as the current
default == _fullboot. When we globally flip and make snapshots the default,
these tests would fail and we are moving them over so that when we flip your
tests still pass.
https://groups.google.com[]forum/#!topic/mobile-ninjas/Y69PTAT5GyY
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=216634430
- Always clip to period duration for the last chunk. We previously
did this only when the last chunk explicitly exceeded the period
end time. We now also do it when the chunk claims to end at the
period boundary, but still contains samples that exceed it.
- If pendingResetPositionUs == chunk.startTimeUs == 0 but the
chunk still contains samples with negative timestamps, we now
clip them by setting the decode only flag. Previously we only
clipped such samples if the first chunk explicitly preceeded the
start of the period.
Issue: #4899
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215763467
- It's a no-op for now
- Renderers that want to support retaining resources will move
some functionality from their disable() implementations into
reset()
- ExoPlayerImplInternal will be updated to not always call reset()
immediately after disable(), which is what will enable resources
to actually be retained.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215729783
This makes the following changes to improve consistency among the PlaybackInfo
values:
1. Update buffered position and total buffered duration after loading period
is set as both values are affected by a loading period update.
2. Add copyWithPosition to allow updating the position without resetting the
loading period.
3. Forward the total buffered duration to playing position updates
as it may have changed with the new playing position.
Issue:#4899
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215712328
When SubtitlePainter positions the cues centred in the given box, it must add
the left offset of the box to get the correct position.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215535289
SubtitleView forwards the cue box position to SubtitlePainter. This should be
the position relative to the canvas of the SubtitleView. Currently, however,
we forward the position relative to the parent of SubtitleView. That causes
problems if SubtitleView has a non-zero offset position to its parent.
Issue:#4788
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215535281
This removes the experimental bandwidth meter and uses it as the new default.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215404065
A lot of methods just forward to other methods and there is no conceivable
way a player should implement it another way. Moving these methods to a
base player class allows to remove duplicated code across our player
implementations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215374192
For example, using ExoPlayer.STATE_IDLE falls back to the Player.STATE_IDLE
automatically and thus there is no need to keep the deprecated members.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215363841
If we prepare a deferred media period before the actual timeline is available,
we either prepare with position zero (= the default) or with a non-zero
initial seek position.
So far, the zero (default) position got replaced by the actual default position
(including any potential non-zero window offset) when the timeline became known.
However, a non-zero initial seek position was not corrected by the non-zero
window offset. This is fixed by this change.
Related to that, we always assumed that the deferred media period will the
first period in the actual timeline. This is not true if we prepare with an
offset (either because of an initial seek position or because of a default
window position). So, we also determine the actual first period when the
timeline becomes known.
Issue:#4873
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215213030
These two methods are meant to indicate to the track selection that it's
started or stopped being used. This is helpful to schedule background tasks
related to track selection (e.g. register network change listeners etc.).
This intention is not clearly stated in the method docs.
Also, all track selections of all prebuffered periods stay enabled in
parallel at the moment. As the whole purpose of these methods is to know
whether dynamic updates via updateSelectedTrack may happen, it's better to
only enable track selections of the current loading media period. That's
similar to how we always forward the loading track selections to the
LoadControl.
This change:
1. Improves the JavaDoc of TrackSelection.
2. Disables track selections if loading moves to another period.
3. Reenables track selection if loading moves back to a previous period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215199987
Switch to the recommended way of checking whether the app is running on a TV
device.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215177587
Extend Sony workaround up to and including Oreo.
Due to a platform issue the Display API couldn't report 1080p UI
and 4k SurfaceView support until Oreo. Since Oreo it is still
common for devices to misreport their display sizes via Display,
so this change switches to using system properties up to and
including Pie.
On Pie treble may prevent writing sys.display-size so check for
vendor.display-size instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214987203
More specifically, if the parts of the Format that are used
for decoder configuration are unchanged.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214791234
If a source is removed from the playlist, the player may still call createPeriod
for a period of the removed source as long as the new timeline hasn't been handled
by the player. These events are stale and can be ignored by using a dummy media
source. The stale media period will be released when the player handles the updated
timeline.
Issue:#4871
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214787090
This simplifies code skipping items in a playlist programatically.
Issue:#4863
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214580742
This method needs to be called whenever the track selection of the current
loading period changes, but also when the loading period itself (and thus
the "loading track selection") changes. These are the same situations in which
we update the loading media period id and thus we can move both updates in
a common helper method.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213959982
From API 23 this uses the timed format queue. Before API 23 the
format is notified as soon as the buffer is queued.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213830729
Before this change we would reset the start trim to zero after initial
configuration (at the start of playback) and after seeking to any position. The
fact that no trimming was applied at the start of playback meant that after the
first period transition we'd see a mismatch between the next buffer timestamp
(equal to the duration of the period taking into account edits) and the duration
of audio submitted to the sink.
This change modifies the behavior so that we reset the start trim to zero only
if some audio was queued since configuration. This is incorrect in the case of
starting playback at a non-zero position, but fixes the common case of starting
at zero. As before, a later seek to any position is handled via a flush and
resets the trim as required.
Transitions from one period to the next are unaffected by this change.
One way to implement start trimming correctly would be to provide the input
buffer timestamp to the audio processors and only trim when handling audio from
the start of the stream, but that is a larger change so left for later.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213828511
After a period transition the first buffer queued has the sum of previous period
durations added to its source presentation timestamp. These durations take into
account gapless edits, but the check on the timestamp was based on the submitted
frame count, not the frame count after trimming.
This change fixes an issue where audio/video would gradually drift apart due to
accumulated error in the audio track position, which could lead to freezing due
to the audio renderer stopping being ready and switching to the standalone media
clock.
Issue: #4559
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213819908
Fixed and random track selection were still overriding the deprecated version
of updateSelectedTrack.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213637728
The only use of track selection factories is as adaptive track selection factories
in the DefaultTrackSelector. Using the fixed track selection factory here is dangerous
as it will throw if more than one track is selected.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213637500
With default of value set to -1, every single dropped frame is reported because of expression: if (droppedFrames >= maxDroppedFramesToNotify) { maybeNotifyDroppedFrames(); }
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213502573
The decoder doesn't claim to be adaptive, but if we're staying
in the same resolution we'll try and re-use the decoder anyway.
The H264 decoder can't handle this case on the Tab 4 can't deal
with this case.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213478378
This doesn't break apps which violate this policy. But it creates a clear
warning which is also likely to be reported in analytics tools.
Issue:#4463
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213442510
The DefaultTrackSelector can now be constructed without leaving out a
vital part of the initialization. This allows this new simple factory method.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213438163
Currently there is no way to disable (or reduce) the logcat output generated
by ExoPlayer.
Issue:#4665
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213421072
This allows creating multiple HLS media sources from a single Factory, as
required by the interface.
Issue:#4814
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213297850
ExoPlayer can be run on a background thread, but some components (UI and IMA)
only support players on the main thread. This adds some documentation and
assertions for that.
To simplify assertions, this also moves the getApplicationLooper method from
ExoPlayer to Player.
Issue:#4439
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213280359
Kotlin will throw NPE whenever a method returns null or an interface is
called with a null parameter and the respective values are not marked as
@Nullable.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213262886
To check the validity of a window index it needs to be compared with a greater
or equal sign to the window count.
Issue:#4822
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213234403
Also prevent an unnecessary allocation when the removed range is empty.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212993427
Not having this annotation may cause Kotlin implementations to fail.
Issue:#4802
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212980643
If we can select a track that has a strictly higher score than a
selection already made for a renderer of the same type, we should
prefer it.
Issue: #4711
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212835895
- Make addMediaSource a specific case of addMediaSources.
- Make clear a specific case of removeMediaSourceRange.
- Make removeMediaSource a specific case of removeMediaSourceRange.
- Remove the unnecessary message handling and constants.
- Move a method so that depending appears before depended.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212809667
This allows to update the shuffle order after the ConcatenatingMediaSource
has been created. ShuffleOrder objects should be immutable to ensure thread
safety and thus there is no way to do this currently.
Issue:#4791
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212443146
- Fixes the referenced issue.
- Provides more consistent behavior for the edge case of empty
chunks (i.e. chunks containing now samples). Format changes
will now always be reported for such chunks, unless the empty
chunk is discarded from upstream before there's a chance to
do so.
Issue: #4533
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212443043
When the stream is changed in the audio renderer, the timestamps of the
samples can no longer be expected to match the calculations in the AudioSink.
This change tracks the samples at which the stream is changed and notifies the
AudioSink of the discontinuity.
Issue:#4559
Issue:#3829
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212435859
When a reset is pending the sample queues normally contain pre-seek
samples (which will be emptied when a pending load is canceled). The
position passed to discard will be a post-seek position. I don't
think anything bad happened in any of the cases being changed, but
discarding is unnecessary in such cases, and reasoning about such
cases is difficult.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212435556
- This makes it so that onDownstreamFormatChanged will occur before the corresponding
renderer event. This was not previously the case, since the renderer would typically
read the format (and report its event), then a sample (causing the
onDownstreamFormatChanged event).
- The remaining ones to update are ChunkSampleStream (DASH + HLS), which will be done
in a way that fixes#4533, and HLS.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212434874
If there's already a pending reset, we need only update the pending
reset position. We can currently end up calling cancelLoading more
than once on the loader for the same task, which is hard to reason
about (although I don't think anything actually broke in practice).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212432266
We currently apply the track.timescale whereas we should be applying the
track.movieTimescale. The parsing for the trak atom does this correctly
and the duration from the trak atom currently always takes precedence over the
durations from the stbl atoms as it's always larger.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212421687
Ignoring all edit lists if they don't start with a keyframe causes A/V sync
issues when valid edit lists are applied at the beginning.
This change allows such edit lists again but removes all samples before the
first keyframe (these samples would be ignored by the renderer anyway if at
the beginning OR cause visible distortions when appended to an unrelated
keyframe).
Issue:#4774
Issue:#4348
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212244407
- There's no particular need to read or skip a sample before notifying
- Add missing isPendingReset check
Issue: #4533
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211959762
The default character set is always UTF-8 anyway on Android, but
we don't want our code to behave any differently where it's not
(e.g. robolectric test runs could potentially run in an environment
where UTF-8 isn't the default?).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211953885
1. Currently, we may throw source info refresh errors while the previous media
period is still playing.
2. We don't throw if the next period in a playlist fails to prepare and the
previous renderers are all disabled.
3. We throw source info refresh errors for playlists before playback reaches
the culprit source.
This change:
1. Defers the exceptions until all existing media periods have been played.
2. Checks for period preparation exception if the next period is not
getting prepared and the renderer time reached the next period.
3. Does no longer throw from ConcatenatingMediaSource.maybeThrowSourceInfo
RefreshError. The deferred media periods take care of that for each source
individually.
Issue:#4661
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211819436
To report DRM session metrics in the future as part of the listener, we need
a callback at the end of the drm session to get the final metric state.
For completion, the session acquired callback is also added.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211328412
Also make some javadocs more consistent with the rest of the library.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211071559
The current structure tries to associate events to media periods and windows
based on the reported values and the current timeline. However the reported
EventTime may not always be consistent in case the timeline doesn't contain
windows or media periods yet or not anymore.
The recent changes to MediaPeriodId allow to use it as a unique identifer for
media periods independent of the timeline. This enables more accurate tracking
of the media period queue and prevents reporting events with inconsistent
data.
Issue:#4492
Issue:#4634
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210713120
This provides the list of currently buffered media chunks and iterators over
the potential next chunks to the track selection. Having these two parameters
enables more advanced decision logic based on this data.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210551812
This fixes or suppresses all reported issues by the code review linter tools.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210107759
There are C.CLEARKEY_UUID.equals(uuid) checks in FrameworkMediaDrm,
so uuid needs to be CLEARKEY_UUID, not COMMON_PSSH_UUID
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210094372
- Add @Deprecated on overrides of deprecated method.
- Suppress deprecation warnings where appropriate.
- Use non-deprecated alternatives where appropriate.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210092434
This prevents problems caused by unintended double-registration of the same
transfer listener.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210078454
This option is currently not available as a non-null adaptive track selection
has to be provided. Adds a parameter "forceHighestSupportedBitrate" which
corresponds to the default fixed track selection for audio and video.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210073675
At the point of starting to play a postroll, source info refreshes for future
postroll ads in the same ad group would cause a seek that incorrectly identified
the media period to play as the content media period. Fix the logic in
getAdGroupIndexForPositionUs to address this.
Also handle empty postroll ad breaks by resetting the expected ad group index
when we send content complete.
Issue: #4710
Issue: #4681
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210071054
Similar to getBufferedPosition and getCurrentPosition, getDuration should
mention that it also returns the duration of the current ad.
And, also similar to getContentBufferedDuration and getContentPosition, a
new method getContentDuration simplifies querying the content duration while
playing an ad.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209914696
The response headers of the last load are available from the loading source
when creating media source events and can be easily forwarded.
Issue:#4361
Issue:#4615
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209900693
The doc can be improved by enumerating and linking all possible values from
the interface doc.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209772309
Apps targeting P or later now must request this permission in order to
use foreground services.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209762160
Also remove NonNull, since we assume NonNull by default. Except
where explicitly overriding a method with NonNull annotated args,
in which case we're still expected to use it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209758204
Some tests were flaky because of the PlayUntilPosition action which called
player.setPlayWhenReady from the wrong thread. Also fixed some other misc
flakiness.
ExoPlayerTest seems to be non-flaky now (tested with 10000 runs).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209743076
They don't need to be accessed publicly and are can be moved into the
respective chunk sources. This is the same structure used for Dash.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209507217
The MediaPeriodId with index is only properly defined together with a
timeline containing the index. Changing it to the period uid allows to use
the MediaPeriodId independent of the corresponding timeline.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209430257
The reason for the change is that variable substititution requires
master playlist variable definitions at the moment of parsing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=208997963
When playing a playlist where the exact maximum input size is known from the
container for each item, it may be necessary to recreate the decoder to increase
its maximum input buffer size at the point of transitioning from one item to the
next, which can make transitions non-seamless.
Scale up the initial video decoder maximum input size so playlist item
transitions with small increases in maximum sample size don't require
reinitialization.
Issue: #4510
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=208650244
Also fix an NPE in FfmpegAudioRenderer if sampleMimeType wasn't set.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=208230947
Also add support for parsing PlayReady DRM information
Issue:#4180
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=208094290
Future changes for checking codec capabilities will go in the renderer rather
than in the codec selector, so the codec selector only needs a MIME type as
before.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=208076716
Add automatic audio focus handling to SimpleExoPlayer. Audio focus
handling is an opt-in feature that can be requested by passing
the system's AudioManager and an AudioFocusConfiguration to
SimpleExoPlayer.setAudioFocusConfiguration.
When audio focus is being managed by SimpleExoPlayer, the player
will transparently handle pausing playback during
AUDIOFOCUS_LOSS_TRANSIENT, as well as lowering playback volume
during AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=208045732
Also locally cache length in BaseDataSource and use zero cost
castNonNull to make sure there's no performance regression.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=207715734
* Make dedicated section in RELEASENOTES
* Clean up AMR FACTORY
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=207550281
Lint likes all constants for an IntDef to be declared explicitly
in switch statements.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=207545682
Lint likes flags to be declared in this way, for safety, apparently
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=207545382
This CL adds support for seeking witin TS streams by using binary search. For
any seek timestamp, it tries to find the location in the stream where PCR
timestamp is close to the target timestamp, and return this position as the
seek position.
Github: #966.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=207529906
For now, just allow any prefix (and don't check the namespace).
Checking the namespace requires turning on the XmlPullParser
namespace awareness feature, but this can only be done before
parsing, and I think requires us to specify the namespace when
querying other attributes. This would also risk breaking services
who currently don't set namespaces correctly.
It's possible we'll run into similar issues with the few other
tags (e.g. mspr:pro). We should revisit enabling namespace
awareness if/when we see this.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=207526883
EventSampleStream.readData required eventStreamUpdatable to be
false for END_OF_STREAM to be returned, but it was only being
set to false when the manifest became static. This change also
sets it to false if the period is not the last one in a dynamic
manifest. It also renames it the parameter to appendable, since
that's what it really represents. Events may still be removed
from the start of the EventStream as the period starts moving
out of the live window.
Issue: #4492
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=207517265
- Use ConstantBitrateSeeker to implement seeking for ADTS format. Since most
ADTS streams are VBR, we use the average bitrate of the first 1000 frames as
the average bit rate.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=207509651
Currently, MetadataRetrieverImpl uses MediaCodecVideoRenderer to renderering
frames to capture. It suffers from 2 issues:
- MediaCodecVideoRenderer has a lot of logic to time frame release, including
drop frames if late or try to keep up with feeding speed etc... These are not
necessary at all for frame retrieval.
- MediaCodecVideoRenderer always tries to render 1 frame after video surface
update. This may some times lead to the wrong image being rendered for
MetadataRetriever.
This CL replaces this with a custom video renderer, that does not time frame
releases, and only render first frame after position reset / renderer
re-enabling.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=207276937
The error is spurious, and is due to an incorrect annotation in
the framework.
[Internal: b/32137960]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=207234603
For background on why doing this works, see below. I don't want to change
how we get our Cipher instance in non-test code, since PKCS7 always works
on Android. It's only when the tests are running on a non-Android host
machine that they can fail. An alternative would be to make it an androidTest,
but androidTests are slow.
------
Background:
"While Java considers PKCS5 and PKCS7 padding to be the "same" (and
one should always use the string "AES/CBC/PKCS5Padding" because
"AES/CBC/PKCS7Padding" will cause NoSuchAlgorithmException to be thrown
when initializing an AES block cipher using the Java crypto API), I
consider this a gross misnaming in the Java platform because the pure
technical definitions of these paddings are not the same."
Ref: https://stackoverflow.com/questions/10193567/java-security-nosuchalgorithmexceptioncannot-find-any-provider-supporting-aes-e
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=207234518
