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
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
Remove all generic arrays from this class.
FakeAdaptiveMediaPeriod.java:171: warning: [rawtypes] found raw type: ChunkSampleStream
return new ChunkSampleStream[length];
^
missing type arguments for generic class ChunkSampleStream<T>
where T is a type-variable:
T extends ChunkSource declared in class ChunkSampleStream
PiperOrigin-RevId: 284761750
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
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
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
