When the ctts contained an entry that had a 0-valued entry count, the
parser would miss every other entry, failing the final assertion.
The standard does not seem to prevent the value 0 in the sample_count
field, so we need to allow it.
Issue: #1326
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117241945
When the edited sample sequence does not contain any sync sample Exoplayer does not provide
support. This CL changes the ArrayIndexOutOfBoundsException for a more explicative
ParserException.
Issue: #1336
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117241805
The MP4 standard considers the udta box as a regular container box. Quicktime, however,
considers it as a container (of only leaf atoms) that can have a terminating 32 bit
integer with value 0. Since this breaks the principle of not having content in container
boxes, this CL considers the udta box as a leaf box that contains other boxes and does
the parsing manually.
Issue: #1315
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117237255
This fix derives from issue #1308, which came up in unfragmented mp4 files.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117236416
The parsing of multiple moov boxes for a single ExtractorOutput incurred in
an assertion failure due to repeated track declarations. This CL makes each
new moov box replace any previous one. This change is transparent to the
client, no flags are provided to allow this feature.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117236246
The minimum compression ratio matches the Nexus 5X MPEG-4 video decoder.
Issue: #1290
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117234657
If a container box is empty, it is never removed
from the container box stack, breaking the extractor.
Issue: #1308
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117228211
- Made enabledRenderers an array to avoid loads of method calls.
- Made if so that enabled renderers are always called in a consistent
order, rather than their order changing if they're enabled/disabled
over time. This is likely to make performance more predictable.
- Split out reading of resets into a separate method. This method is
now called directly after seeking on the source, so as to ensure
instant propagation of the new position from source->renderers in
the common case.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117225639
Some devices fail to decode an avc3 stream that doesn't start with an SPS (for
example, if an access unit delimiter appears first). Workaround the issue by
discarding input sample data up to the first SPS on those devices.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117224602
When reading unknown duration files with CBR seeking, the Mp3Extractor could
try to read sample data from 0. This happened because synchronization did not
skip over the ID3 data when it immediately found valid frames. When the invalid
sample data is read, the extractor tries to resynchronize from the next byte
(at offset 1), and this fails because the ID3 data at the start of the file is
longer than the synchronization search distance.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117224270
This is needed to support fully demuxed audio in HLS. For the
sample I have the video (only) variant still declares an AAC
stream. I suspect there's at least one toolchain out there that
hardcodes H264 and AAC streams in TS output.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117224224
The idea here is that you'll be able to feed data through an extractor
to a FakeExtractorOutput, then do the same again with some or all of the
simulated flakiness settings toggled on FakeExtractorInput, and then
assert that the output was the same in both cases.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117224019
The upstream source (or its stream) should always provide data
starting from a sync frame, so this logic shouldn't be necessary.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117220759
allow "center".
This value (and not "middle") is listed in
https://w3c.github.io/webvtt/ ( WebVTT: The Web Video Text Tracks Format, Draft
Community Group Report, 21 December 2015).
Leaving the behavior for "middle" unchanged.
It was the value listed in older drafts, e.g.
https://www.w3.org/TR/2014/WD-webvtt1-20141113/ ( W3C First Public Working
Draft 13 November 2014 )
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117220612
Failing to parse a UUID from a ContentProtection should only
result in filtering if there was actually a cenc:pssh element
there for us to get it from.
Issue: #1256
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117220417
This avoids accessing PtsTimestampAdjuster through a thunk method,
and allows the PesReader classes to be static, which is nice in
general.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117220139
- Use it to simplify a bunch of tests.
- Will also replace RecordableExtractorInput in a subsequent CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117220030
Set the duration to the sum of the final period's start
+ duration (if available) if MPD@mediaPresentationDuration
isn't set in the manifest.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117141391
- readFully calls when reading a string or varint may have 0 length.
The behavior of a 0 length read isn't well defined either at the
ExtractorInput or DataSource level, particularly when the read may
also coincide with EOS. We'll work on defining these cases properly
going forward, but in the meantime this fix avoids attempting 0
length reads.
- [Aside] UTF8 the is guaranteed default charset on Android.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117130356
DTS Express (which is DTS LBR according to http://www.mp4ra.org/codecs.html) is
not supported for passthrough playback currently. Associate a different MIME
type with it so that we don't try to use DTS passthrough for playing DTS
Express.
The MIME type for DTS Express is just vnd.dts.hd, with a profile parameter
indicating that it's DTS Express rather than one of the other formats.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117129583
