Unfortunately devices such as the MI 8 do not provide an alternative
working decoder. Some Vivo devices do provide one though.
PiperOrigin-RevId: 288911897
This improves readability by making clearer that reading no bytes from
the input in readFrames() is an expected case if the buffer is full.
PiperOrigin-RevId: 288711841
Currently, seeks are only tracked if both the start and the end of the seek
is within the same window. This means no seeking state is reported if the
playback switches to a new window during the seek.
This problem is fixed by tracking seek start and end events in all cases,
but only report seeking state once the window becomes the foreground window.
PiperOrigin-RevId: 288706674
These make the interesting bits of each assertion harder to follow imo.
Also remove all the assertWithMessage() calls at the same time, Olly
convinced me these are rarely useful since you can click from the stack
trace to the failing line in the IDE.
PiperOrigin-RevId: 288470704
- Simulate IO exceptions in the test using FlacBinarySearchSeeker for
seeking in FlacExtractorTests. This makes the test slower but covers
more test cases.
PiperOrigin-RevId: 288285057
There's currently no rendering support for ruby text in SubtitleView
or SubtitlePainter, but this does have a visible impact with the
current implementation by stripping the ruby text from Cue.text
meaning it doesn't show up at all under the 'naive' rendering.
This is an improvement over the current behaviour of including
the ruby text in-line with the base text (no rubies is better than
wrongly rendered rubies).
PiperOrigin-RevId: 288280416
This typo was introduced in ddb70d96ad
when migrating a static method with parameter `durationUs` to an
instance method where the correct field to use was `blockDurationUs`
(but `durationUs` also exists).
The test that catches this was only added in 45013ece1e (and
therefore configured with the wrong expected output data).
issue:#6833
PiperOrigin-RevId: 288274197
It's not used. I was trying to work out how to correctly cascade my
text-combine-upright styling, but deleting the method seemed easier...
PiperOrigin-RevId: 287989480
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
Relying on the precedence of spans seems risky - I can't find it
defined anywhere. It might have changed in Android 6.0?
https://stackoverflow.com/q/34631851
PiperOrigin-RevId: 287989365
-- Optimize Mp4Extractor for AC-4
-- Optimize FragmentedMp4Extractor for AC-4
-- Add test case for AC-4 in MP4
-- Add test case for AC-4 in Fragmented MP4
It's unreliable for at least one IMA ADPCM file I've found.
Calculating the blockIndex to seek to using exact properties
also seems more robust.
Note this doesn't change anything for the existing PCM test,
since averageBytesPerSecond is set correctly. It does make
a difference for an upcoming IMA ADPCM test though.
PiperOrigin-RevId: 287814947
An experiment with this algorithm didn't show positive results. We can
therefore keep the simpler default algorithm.
Startblock:
<unknown commit> is submitted
PiperOrigin-RevId: 287807538
