Add fields in DecoderCounters for computing the average video frame
processing offset.
The MediaCodecVideoRenderer reports the video frame processing offset
and the demo app presents it on the debug information.
PiperOrigin-RevId: 294677878
This allows to simulate samples in a stream more accurately
particularly when streams are prepared at a non-zero position and
issuing a sample with position=0 is not expected.
Also makes seek more realistic by also issuing one sample again.
PiperOrigin-RevId: 293344081
Once we receive an update from a masked source, we first start the
preparation of an already pending period, and only then notify the
player of the new timeline. If the period prepares immediately inline,
the MediaPeriod.onPrepared callback arrives before the
onPlaylistUpdateRequested call in the Player. THis is the wrong order
and causes issues when the player tries to lookup information in the
timeline that doesn't exist yet.
This change fixes preroll playbacks before live streams.
PiperOrigin-RevId: 293340031
This change deprecates Player.onPlayerStateChanged(boolean pwr, int state). It removes deprecation for trivial cases. I'll remove other deprecated usages (mostly in ui module) in follow-up CLs to not bloat this CL.
PiperOrigin-RevId: 292917872
Before:
No matching span found
in text : Text with combined section.
expected : start=10 end=18 type=HorizontalTextInVerticalContextSpan substring='combined'
but found:
After:
No matching span found
in text : Text with combined section.
expected: start=10 end=18 type=HorizontalTextInVerticalContextSpan substring='combined'
but found no spans
PiperOrigin-RevId: 292878264
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
Allows items to be added to the queue once the sample stream has already been created.
Means tests can simulate data not all being available at the start.
PiperOrigin-RevId: 290613392
*** 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
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
Ultimately we only care if the style is both bold & italic, if some of
those are specified multiple times there's no problem.
PiperOrigin-RevId: 288862235
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
This offset allows to improve the calculated live offset because it
can take known client-server time offsets into account.
PiperOrigin-RevId: 285970738
This indicates the extractor has output a Format with a specified
maxInputSize that's too small. Failing in FakeTrackOutput ensures
this doesn't happen during Extractor tests.
PiperOrigin-RevId: 285776069
It's technically possible to output a seekable SeekMap with unknown duration. This can occur if the media defines seek points but doesn't define either the overall duration or the duration of the media from the last seek point to the end.
PiperOrigin-RevId: 285769121
