Instead of having types in flac inherit types in vorbis, make types in
vorbis inherit types in flac. This is a bit of a hack and somewhat
messy, but it retains backwards compatibility.
Collapse the two variations of `VorbisUtil.buildMetadata` into a single
method called `VorbisUtil.parseVorbisComments` that only takes a list
of vorbis strings, compared to previously where it would take strings
and picture frame instance. Any code that relied on the old signature
now either concatenates picture frames and vorbis comments or copies
vorbis comments into an existing metadata instance.
Simplify how the comment header is parsed and eliminate a few possible
bugs in the process, such as:
- Metadata being overwritten directly by the comments header.
- The packet being rewound to 0 if it cannot find a comment header,
which might result in the cursor being moved to a bad position.
In the old `flac` module, superclass the deprecated types under the
moved types in the `vorbis` module. This ensures backwards compat
with existing library users.
Refactor the overall module to place the unified vorbis tags into a
single package called `vorbis`. Also re-intoduce the vorbis tags
in their original `flac` module, but deprecate them.
Populate ICY headers into MediaMetadata so that they can
propagate to the app via AnalyticsListener#onMediaMetadataChanged().
This change copies IcyHeaders.name into MediaMetadata.description
and IcyHeaders.genre into MediaMetadata.genre.
Note: MediaItem.metadata maintain their precedence and overwrite any
ICY headers parsed.
Issue: google/ExoPlayer#9677
PiperOrigin-RevId: 410495676
Populate ICY headers into MediaMetadata so that they can
propagate to the app via AnalyticsListener#onMediaMetadataChanged().
This change copies IcyHeaders.name into MediaMetadata.description
and IcyHeaders.genre into MediaMetadata.genre.
Note: MediaItem.metadata maintain their precedence and overwrite any
ICY headers parsed.
Issue: google/ExoPlayer#9677
#minor-release
PiperOrigin-RevId: 410495676
The presentation time in fMP4 is calculated by adding and subtracting
3 values. All 3 values are currently converted to microseconds first
before the calculation, leading to rounding errors. The rounding errors
can be avoided by doing the conversion to microseconds as the last step.
For example:
In timescale 96000: 8008+8008-16016 = 0
Rounding to us first: 83416+83416-166833=-1
#minor-release
PiperOrigin-RevId: 406809844
The presentation time in fMP4 is calculated by adding and subtracting
3 values. All 3 values are currently converted to microseconds first
before the calculation, leading to rounding errors. The rounding errors
can be avoided by doing the conversion to microseconds as the last step.
For example:
In timescale 96000: 8008+8008-16016 = 0
Rounding to us first: 83416+83416-166833=-1
#minor-release
PiperOrigin-RevId: 406809844
Test file produced with:
$ MP4Box -add "sample.mp4#video:colr=nclc,1,1,1" -new sample_18byte_nclx_colr.mp4
And then manually changing the `nclc` bytes to `nclx`.
This produces an 18-byte `colr` box with type `nclx`. The bitstream of
this file does not contain HDR content, so the file itself is invalid
for playback with a real decoder, but adding the box is enough to test
the extractor change in this commit.
(aside: MP4Box will let you pass `nclx`, but it requires 4 parameters, i.e. it
requires the full_range_flag to be set, resulting in a valid 19-byte colr box)
#minor-release
Issue: #9332
PiperOrigin-RevId: 405842520
- This CL does not introduce functional changes.
- This change will allow searching for the clli box while
parsing the mdcv box in order to construct the HDR
static info contained in ColorInfo.
#minor-release
PiperOrigin-RevId: 405656499
When ExtractorInput.getLength() returns a defined length, the
SubtitleExtractor will create a buffer of the same length, call
ExtractorInput.read() until it has read the input bytes, plus one more
time where ExtractorInput.read() returns RESULT_END_OF_INPUT. The last
call to ExtractorInput.read() however will make the SubtitleExtractor to
increase its buffer (including a copy) unnecessarily.
This change makes the SubtitleExtractor avoid calling
ExtractorInput.read() if the expected number of bytes have already
been read, so that the internal buffer does not grow.
PiperOrigin-RevId: 402583610
Before this change, the SubtitleExtractor did not mark the limit
of the input buffer, thus the SubtitleDecoder attempted to decode
more bytes. If the subtitle file had a new line at the end, this
bug would make the SubtitleDecoder append an line break after the
last subtitle.
PiperOrigin-RevId: 402523039
The previous implementation did the following (after skipping any ID3
headers at the start of the stream):
1. Skip forward byte-by-byte looking for a sync word (0xFFF)
2. Assume this indicates the start of an ADTS frame and read the size
a) If frameSize <= 6 immediately return false
3. Skip forward by frameSize and expect to find another ADTS sync word
(with no further scanning).
b) If we find one, great! Loop from step 2.
a) If we don't find one then assume the **last** sync word we found
wasn't actually one, so loop from step 1 starting one extra byte
into the stream. This means we're looking for a sync word we would
have skipped over in step 3.
The asymmetry here comes from the different handling of frameSize <= 6
(immediately return false) and frameSize being 'wrong because it doesn't
lead to another sync word' (scan the file again from the beginning for
alternative sync words).
With this change both these cases are handled symmetrically (always scan
for alternative sync words). Step 2a) becomes the same as 3b): Loop back
to the beginning of the stream with an incremented offset and scan for
another sync word.
#minor-release
PiperOrigin-RevId: 397285756
SubtitleExtractor is using IndexSeekMap with only one position to
indicate that its output is seekable. SubtitleExtractor is keeping Cues
in memory anyway so more seek points are not needed. SubtitleExtractor
gets notified about seek occurrence through seek() method. Inside that
method extractor saves seekTimeUs, and on the next call to read()
extractor outputs all cues that should be displayed at this time and
later.
PiperOrigin-RevId: 395477127
Simplifies the SubtitleExtractor implementation. Makes the extractor
more aligned with the Extractor interface documentation by removing
STATE_DECODING in which extractor was doing nothing in term of input
and output while returning RESULT_CONTINUE at the same time.
PiperOrigin-RevId: 395267468
This typically happens if there's a discontinuity in the stream.
It's better to say we don't know, than it is to return a negative
position.
Issue: #8346
#exofixit
#minor-release
PiperOrigin-RevId: 395224088
Extractor was not calling endTracks() and seekMap() on the
extractorOutput which are required to finish the preparation.
At that point extractor does not support seeking.
PiperOrigin-RevId: 393994848
Samples are serialized using our custom CueEncoder. Information in
which format samples are encoded is needed by Renderer to decide which
decoder to use. Extractor receives Format object in the constructor and
prepares new Format object with sampleMimeType moved to codecs field
and new sampleMimeType set to "custom serialized exoplayer Cue".
PiperOrigin-RevId: 391739866
SubtitleExtractor.release() releases the underlying SubtitleDecoder.
This change introduces the STATE_RELEASED state. The extractor
handles the new state in the read() and seek() methods.
PiperOrigin-RevId: 391046478
SubtitleExtractor is a component that extracts subtitle data taken from
ExtractorInput into samples. Samples are pushed into an ExtractorOutput
(usually SampleQueue). As a temporary solution SubtitleExtractor uses
SubtitleDecoder to extract Cues from input data.
PiperOrigin-RevId: 390319875
- Fix use of getTimestampOffsetUs in TsExtractor where
getFirstSampleTimestampUs should have been used.
- Don't reset TimestampAdjuster if it's in no-offset mode.
- Improve comment clarity
#minor-release
PiperOrigin-RevId: 388682711
- Use timestampOffsetUs == C.TIME_UNSET directly as the way of
determining whether the adjuster has determined the offset,
rather than relying on lastSampleTimestampUs checks for this.
- Remove comment referring to lastSampleTimestampUs as holding
the "adjusted PTS". Its value may not have originated from a PTS
timestamp. It's also confusing to refer to it as "adjusted"
given timestampOffsetUs has not been applied to it.
- Fix PassthroughSectionPayloadReader to make sure it'll never
output a sample with an unset timestamp.
#minor-release
PiperOrigin-RevId: 388226180
The dokka javadoc generation tool complains when parameter names don't match between a method and its override. This change updates occurrences where there is currently a mismatch.
Notable renamings that might be controversial:
- `onPlaybackStateChanged(int state)` to `onPlaybackStateChanged(int playbackState)` affected a lot of lines but seems more consistent with other '-Changed' methods.
- `handleMessage(int messageType, Object payload)` to `handleMessage(int messageType, Object message)`
- `ExtractorInput` and `DataSource` inherit `DataReader` which had `read(byte[] target, ...`, while data sources normally called the first parameter `buffer`. I have standardized these all to use `buffer` even though it looks out of place in the `ExtractorInput` interface (which has more `read` methods with `target`).
PiperOrigin-RevId: 387290360
* @Flags is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs.
(see go/java-style#s4.8.5-annotations)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.
This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.
#codehealth
PiperOrigin-RevId: 386849198
More information: go/checker-3130-lsc
Tested:
Some test failures are present, but the CL author has decided to mail the change anyway
PiperOrigin-RevId: 379622938
Note that this removes a workaround for malformed content, in which the
track_ID is set incorrectly. It's unclear there was sufficient reason to
implement that workaround, and so it's preferable to remove it, rather
than implementing the concept of unrecognized tracks, which would be
needed to keep it and to also fix this issue.
Issue: #9056
#minor-release
PiperOrigin-RevId: 379506261
As of [JDK-8247957](https://bugs.openjdk.java.net/browse/JDK-8247957), doclint
no longer supports html4.
Tested:
Some test failures are present, but the CL author has decided to mail the change anyway
PiperOrigin-RevId: 378819179
