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
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
-- 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
- Make extractor output samples that are uniformly distributed
with respect to time, with a target of ~10 samples per second.
The old approach could in theory put every frame into its own
sample, which would be very inefficient downstream because we'd
need to pass them individually to MediaCodec. It could also put
data corresponding to a long duration of time into a single
sample (e.g. if the sample rate of the content is low), which
is bad downstream because we decide whether to set the decodeOnly
flag on a per sample basis. More generally, the new approach
is more predictable :).
- Stop using the WavSeekMap to get sample timestamps, and instead
calculate them directly from the number of frames output. It's
more obviously correct, particularly for data formats like IMA
ADPCM where we'll need to adjust the data prior to output.
PiperOrigin-RevId: 285750010
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 makes the format metadata null (instead of an empty Metadata
object) when it is not provided, and is therefore consistent with the
other extractors behavior.
PiperOrigin-RevId: 284171148
The capture frame rate is currently available both via Format.metadata
and decoded in Format.frameRate. As the container Format.frameRate may
be useful to apps, only store the capture frame rate in metadata (apps
will need to decode it but can now access the container frame rate too).
PiperOrigin-RevId: 284165711
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
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
A previous change switched to calculation of the bitrate based on the
first MPEG audio header in the stream. This had the effect of fixing
seeking to be consistent with playing from the start for streams where
every frame has the same padding value, but broke streams where the
encoder (correctly) modifies the padding value to match the declared
bitrate in the header.
Issue: #6238
PiperOrigin-RevId: 261163904
* Add AC-4 MIME type definition
* Add AC-4 format support in Mp4Extractor and TsExtractor
* Add AC-4 Extractor
* Add AC-4 playback support in MPEG-4, MPEG-DASH, TS and HLS
The buffered position is currently based on the mimimum queued timestamp of
all AV tracks. If the tracks have unequal lengths, one track continues loading
without bounds as the "buffered position" will always stay at the shorter
track's duration.
This change adds an optional buffer flag to mark the last sample of the
stream. This is set in the Mp4Extractor only so far. ExtractorMediaSource
uses this flag to ignore AV streams in the buffered duration calculation if
they already finished loading.
Issue:#3670
PiperOrigin-RevId: 229359899
- Increase the search window size to fix TS seeking for problematic
media we've had provided to us.
- As per my comments on the issue, we should look at doing more here
to better fix the problem. This will solve the worst of the
immediate problem, however.
- The memory usage is non-trivial, particularly with the increased
search window size. I've made the allocations only live whilst
determining duration and seeking to address this. I've done the same
for PS just for consistency.
Issue: #5097
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221449988
