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
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
The presentationTimeOffsetMs may be C.TIME_UNSET for VOD content
and shouldn't be used in calculations for the windowStartTime.
PiperOrigin-RevId: 285363095
Keyframe was rendered rather than skipped when performing
an exact seek to a non-zero position close to the start of
the stream.
PiperOrigin-RevId: 284798460
Caveats:
- Block additional data is ignored if the block is laced
and contains multiple samples. Note that this is not
a loss of functionality (SimpleBlock cannot have block
additional data, and lacing was previously completely
unsupported for Block)
- Subrip and ASS samples are dropped if they're in laced
blocks with multiple samples (I don't think this is
valid anyway)
Issue: #3026
PiperOrigin-RevId: 284545197
This change constrains the use of sample state member variables to
writeSampleData, finishWriteSampleData and resetWriteSampleData.
Using them elsewhere gets increasingly confusing when considering
features like lacing in full blocks. For example sampleBytesWritten
cannot be used when calling commitSampleToOutput in this case
because we need to write the sample data for multiple samples
before we commit any of them.
Issue: #3026
PiperOrigin-RevId: 284541942
- Remove "lacing" from member variables. They're used even if
there is no lacing (and the fact that lacing is the way of
getting multiple samples into a block isn't important).
Issue: #3026
PiperOrigin-RevId: 284152447
- Change sampleHasReferenceBlock to a block reading variable, which is
what it is (the distinction didn't matter previously, but will do so
when we add lacing support in full blocks because there wont be a 1:1
relationship any more.
- Move sampleRead to be a reading state variable.
- Stop abbreviating "additional"
Issue: #3026
PiperOrigin-RevId: 284000937
An I/O error could occur while handling the start of an mdta box, in
which case retrying would cause another ContainerAtom to be added. Fix
this by skipping the mdta header before updating container atoms.
PiperOrigin-RevId: 284000715
This parameter is a little confusing, especially as the behaviour
can be surprising if the intended use-case isn't clear. This change
moves the description of the parameter into the class javadoc,
adds context/justification and slims down each method's
javadoc to refer to the class-level.
Related to investigating/fixing issue:#6700
PiperOrigin-RevId: 283724826
This is a minor change ahead of merging a full variant of
https://github.com/google/ExoPlayer/pull/6706, to make
re-buffers less likely.
Also remove variable substitution when parsing
AVERAGE-BANDWIDTH (it's not required for integer attributes)
PiperOrigin-RevId: 283554106
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
When transitioning to a new stream in a different format, the audio
processors are reconfigured. After this, they are drained and then
flushed so that they are ready to handle data in updated formats for the
new stream.
Before this change, some audio processors made the assumption that after
reconfiguration no more input would be queued in their old input format,
but this assumption is not correct: during draining more input may be
queued. Fix this behavior so that the new configuration is not referred
to while draining and only becomes active once flushed.
Issue: #6601
PiperOrigin-RevId: 282515359
flush() is guaranteed to be called in all these cases anyway.
Also clarify documentation for AudioProcessor-specific methods that can
change the 'active' flag.
Issue: #6601
PiperOrigin-RevId: 282515255
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
They are all marked with a JavaDoc comment and the @WorkerThread annotation
which is useful if apps are using threading annotations. All other public
methods in the same classes are marked with @AnyThread to avoid the impression
we forgot to annotate them.
PiperOrigin-RevId: 281490301
The current workaround seems to cause compilation errors inside the
testutils module in Android Studio. This seems to fix them.
This doesn't introduce a circular dependency because it's only
the tests in library-core depending on testutils.
PiperOrigin-RevId: 281318192
Note:
- Fixing this uncovers another bug in how audio processor draining
works, so the test playlist still doesn't play correctly after this
change.
- Once we reconfigure the audio sink based on the ExoPlayer Format
rather than the codec MediaFormat in a later change, this change can
be reverted.
Issue: #6601
PiperOrigin-RevId: 281264149
- Make NonNull, which is already the case when using the manager builder.
- Better document PLAYREADY_CUSTOM_DATA_KEY, now that newPlayReadyInstance
is no more.
PiperOrigin-RevId: 281079288
The implementation of writing HDR10+ static metadata assumed that the
application would use default (big endian) byte order for this metadata but
MediaCodec expects the order to match the specification CTA-861.3.
PiperOrigin-RevId: 281050806
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
Previously the renderer EOS (aka last frame rendered), was reported as soon
as the last encoded frame was queued in the codec renderer.
This leaded to EOS reported too early.
PiperOrigin-RevId: 280456277
This speeds up downloads where segments have the same URL with different
byte ranges. We limit the merged segments to 20 seconds to ensure the download
progress of demuxed streams is roughly in line with the playable media duration.
Issue:#5978
PiperOrigin-RevId: 280410761
Clear state for one mode when entering the other in both SimpleExoPlayer
and SimpleDecoderVideoRenderer. The latter is redundant for the case of
renderers that are used inside SimpleExoPlayer, but seems nice to have.
- Entering Surface mode means receiving a non-null Surface, SurfaceHolder
or TextureView in SimpleExoPlayer, or a non-null Surface in
SimpleDecoderVideoRenderer.
- Entering VideoDecoderOutputBufferRenderer means receiving a non-null
VideoDecoderOutputBufferRenderer in SimpleExoPlayer and
SimpleDecoderVideoRenderer.
PiperOrigin-RevId: 280155151
This aligns the method naming and Javadoc. The only remaining
inconsistency I can see is that the initial reference count for
DrmSession is 0 rather than 1. Unfortunately I think it's not
trivial to get these aligned, because DefaultDrmSessionManager
relies on being able to do something between instantiation and
the DrmSession starting to open the session. In practice this
doesn't really matter, since DrmSessions will be obtained via the
manager, which does increment thee reference count to 1 to be
consistent with how ExoMediaDrm acquisition works.
PiperOrigin-RevId: 280136574
The handling of times wasn't really clear to me, hopefully this more
exhaustive documentation helps a bit.
Also assert the end timecode is the 'correct' length for the format.
PiperOrigin-RevId: 279922369
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 is for consistency with PlayerControlView.
- Also update PlayerNotificationManager notification if shuffle
mode changes. This is for consistency with what happens when
the repeat mode changes. By default the notification will be
unchanged, but custom implementations can extend and then
override createNotification, and given these modes change
infrequently it feels like we can just do this. The alternative
for achieving consistency would be to remove handling of repeat
mode changes.
Issue: #6582
PiperOrigin-RevId: 277925094
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
The framework opus decoder discards some samples after a call to
flush(). Because we flush a decoder that is being retained across an
input format change, this means that the start of audio gets truncated
when transitioning to a new opus stream. See also
https://android.googlesource.com/platform/frameworks/av/+/refs/heads/android10-release/media/libstagefright/codecs/opus/dec/SoftOpus.cpp.
Avoid this by recreating opus decoders instead of flushing them. It
seems fine to do this for all opus decoders as reinitialization should
be cheap, OEM-provided implementations may also discard samples and
playback shouldn't be interrupted on reinitialization due to the
downstream AudioTrack buffer.
PiperOrigin-RevId: 277458759
Update it to throw if hasNext() is false, to match Java's Iterator
interface.
This also simplifies the null-checking annotations required
PiperOrigin-RevId: 277059766
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
*** Original commit ***
Rollback of bf01ff0f60
*** Original commit ***
Use Float.NaN for Cue#DIMEN_UNSET
Float.MIN_VALUE is very close to zero:
"A constant holding the smallest positive nonzero value of type float"
https://developer.android.com/reference/java/lang/Float.html#MIN_VALUE
Float.NaN more clearly conveys this is an invalid number,
and will also more clearly carry over if we do maths on it a...
***
PiperOrigin-RevId: 276674142
*** Original commit ***
Use Float.NaN for Cue#DIMEN_UNSET
Float.MIN_VALUE is very close to zero:
"A constant holding the smallest positive nonzero value of type float"
https://developer.android.com/reference/java/lang/Float.html#MIN_VALUE
Float.NaN more clearly conveys this is an invalid number,
and will also more clearly carry over if we do maths on it accidentally.
***
PiperOrigin-RevId: 276315786
Float.MIN_VALUE is very close to zero:
"A constant holding the smallest positive nonzero value of type float"
https://developer.android.com/reference/java/lang/Float.html#MIN_VALUE
Float.NaN more clearly conveys this is an invalid number,
and will also more clearly carry over if we do maths on it accidentally.
PiperOrigin-RevId: 276277784
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
Without this, a subtitle track empty edit list used to offset the start of
subtitles is ignored.
Also the current code seems to depend on the order in which
we parse the tracks (audio first means we have gapless info when we parse
video track, while video first we wouldn't).
It's not clear why we can't handle both edit lists & gapless info
PiperOrigin-RevId: 276029744
- Leaving GvrAudioProcessor for now.
- Removing GvrPlayerActivity because it was never released. Also removing
related UI classes. These were released, but it's unlikely anyone would
have been using them directly.
PiperOrigin-RevId: 275822516
*** 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
@MonotonicNonNull is not useful if the variable is final, because it's only
assigned once and guaranteed to keep it's current nullability in the same
way as @MonotonicNonNull ensures it's kept non-null after checking.
This way, the workarounds can also be removed.
PiperOrigin-RevId: 275428656
GlViewGroup doesn't work properly as an actual ViewGroup. For example,
it doesn't support addition of child views after instantiation. This
change turns the class into a renderer, which is also more consistent
with other classes in the package.
PiperOrigin-RevId: 275322295
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
Use composition instead.
This makes the null-handling more explicit & complete (previous implementation
tried to prevent null values, but didn't override all mutation methods
e.g. replace(), putIfAbsent() etc.)
PiperOrigin-RevId: 274778513
*** Original commit ***
Remove null-ness of muxedCaptionFormats list
Pre-work for removing HlsMasterPlaylist and HlsPlaylistParser from null-checking
blacklist.
***
PiperOrigin-RevId: 274591502
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
When newIndex overlaps oldIndex with newstarttime < oldstarttime, according to the segNum of endtime
in newIndex and oldIndexLastSegnum to calculate the segmentNumShift.
It's confusing that app:played_color also modifies the colors
that derive from it, but the corresponding setter does not. It
seems generally clearer just to define constants.
PiperOrigin-RevId: 273249557
Move reusable code from LibvpxVideoRenderer to SimpleDecoderVideoRenderer.
Pass outputBuffer to renderOutputBuffer method instead of keeping the reference in the renderer.
PiperOrigin-RevId: 272899549
It's confusing that seekTo(player, windowIndex, positionMs) does
clamping, because it only makes sense if windowIndex is the current
window.
Note: This doesn't actually fix anything (other than code clarity).
In cases where we were passing other windowIndices, we always
passed 0 as the position and so the clamping logic wouldn't have
had any effect.
PiperOrigin-RevId: 272857104
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
