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
Unlike Assertions, the introduced method cannot be disabled and throws
a ParserException instead. This method is meant to replace regular
assertions (which throw RuntimeExceptions) which check input in the
parsing code.
PiperOrigin-RevId: 375085160
First intention to support parsing MPEG-H 3D Audio in ExoPlayer is to
take advantage of parsing capability from MediaParser API in AOSP.
Just with this change ExoPlayer does't support decoding MPEG-H 3D Audio
but can support decoding either by adding decoder with an extension or
by using Android OS which has decoder capability with MediaCodec API.
A TrackGroup must contain the same content in all Formats (except for
the quality, encoding etc). Verify that the language and role flags
are the same and log an error if don't match. Don't throw to avoid
breaking existing use cases that just happen to work by chance.
PiperOrigin-RevId: 365539240
This makes HLS playback less liable to become stuck if discontinuity
tags are inserted at different times across media playlists.
Issue: #8700
Issue: #8372
PiperOrigin-RevId: 362903428
The previous logic was changed under the assumption that the first box
inside a meta box was not always an hdlr box, but this is not true.
#minor-release
PiperOrigin-RevId: 357200713
- Fix comparison between a byte and 0xFF to avoid conversion of 0xFF to
byte and to int again (due to numeric promotion).
- Fix addition of int and byte with most significant bit set. The byte
was incorrectly promoted to an int negative value.
Issue:#8496
#minor-release
PiperOrigin-RevId: 353865751
*** Original commit ***
Rollback of ff8c8645ab
*** Original commit ***
Merge #8401: Initialize Format.codecs from HEVC SPS NAL unit (#8393)
Imported from GitHub PR https://github.com/google/ExoPlayer/pull/8401
This will allow ExoPlayer to check if video track's profile and level are supported by decoder when playing progressive media so...
***
PiperOrigin-RevId: 351139861
*** Original commit ***
Merge #8401: Initialize Format.codecs from HEVC SPS NAL unit (#8393)
Imported from GitHub PR https://github.com/google/ExoPlayer/pull/8401
This will allow ExoPlayer to check if video track's profile and level are supported by decoder when playing progressive media sources.
Merge e582fb91b73c7c95e754167140211d5473c36d14 into 1347d572ef
Issue: #8393
***
PiperOrigin-RevId: 350871621
Imported from GitHub PR https://github.com/google/ExoPlayer/pull/8401
This will allow ExoPlayer to check if video track's profile and level are supported by decoder when playing progressive media sources.
Merge e582fb91b73c7c95e754167140211d5473c36d14 into 1347d572ef
Issue: #8393
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/ExoPlayer/pull/8401 from equeim:hevc-codecs e582fb91b73c7c95e754167140211d5473c36d14
PiperOrigin-RevId: 350738065
This will allow ExoPlayer to check if video track's profile
and level are supported by decoder when playing progressive media sources.
Also fix typo in AvcConfig.
- In slow motion videos flattened by Samsung, the saut box is kept but
only have the 4 first bytes (author field).
- In Samsung normal videos, the recording mode is zero.
In these cases, skip this box.
PiperOrigin-RevId: 347577303
Fix Matroska, Heif, FLAC, Ogg, Opus, Vorbis
extractor nullness check.
There should be no functional change.
Every media that fail to be parsed should still fail.
Every media that parsed successfully should still succeed.
This refactor aims to push all nullness constraints up the call stack to clarify each API nullness contract. This ensures implementation and caller have to prove their respective contract close to where such logic is implemented. This also allows to fail early if an nullness contract is broken instead of deep in the call stack.
For example, by adding a requirement that all implementation of `StreamReader.readHeaders` have to initialize `setupData.format` if the return false, each overriding method is forced to prove this next to the logic initializing it. This also means the runtime check might not be needed because the nullnessChecker can prove itself the contract holds.
This is in contrast with adding a null check at the point of usage, which will not catch logic errors where they are produce, but later when they are perceived; making it harder to debug and catching the issue at run time instead of compile time.
#exofixit
PiperOrigin-RevId: 346163124
Retrieve the capture frame rate and the SVC temporal layer count from
the smta box instead of the meta box because this is what Samsung do. It
is not guaranteed that the meta box will be present and will contain all
the necessary info in all slomo files.
PiperOrigin-RevId: 345639680
This was reported for SSA/ASS in PR #8265, but it seems to me the
SubRip part of the Matroska spec is similarly loose, so this change
handles null-terminated strings in both.
#minor-release
PiperOrigin-RevId: 345452667
This method should be assumed to clear the data of the underlying array
(it will do this if the new limit > data.length).
This means it should only be called (directly) before writing into the
backing array.
It shouldn't be used as a shorthand for position=0, limit=x - those
should be two explicit method calls.
Most of these changes are no-ops, but they make the code more correct.
The TS SectionReader can't be easily changed to be 'safe', because it
relies on sectionData maintaining state between iterations of the while
loop. Instead I've added comments justifying the existing code.
PiperOrigin-RevId: 344515340
This ensures we have full test coverage for proguard configs now.
The only configs not covered by tests are:
- IMA and OkHttp which copy recommended configs from the respective
library. I couldn't reproduce failures by removing them (and thus
couldn't write a test that ensures they are correct).
- Some dontwarn lines that just suppress warnings.
In addition, this change fixes a couple of related issues:
- Moved AV1 proguard config to correct module.
- Removed mentioning of deprecated ExtractorMediaSource from README
- Suppressed warning from IMA code that prevent proguarding under
strict rules
- Fixed wrong proguard exclusion in VP9 module.
- Moved FLAC exclusion (DefaultExtractorsFactory) to correct module.
- Added AlertDialog suppression for de-jetified code.
- Removed unusued dependency from UI module that causes large APK
size increase.
#exofixit
#minor-release
PiperOrigin-RevId: 344427532
* These grouping parentheses are unnecessary; it is unlikely the code will be misinterpreted without them
(see http://go/bugpattern/UnnecessaryParentheses) (2 times)
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/exoplayer/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/exoplayer/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.
#codehealth
PiperOrigin-RevId: 344053269
*** Original commit ***
Suppress warnings in preparation for Checker Framework 3.7.1 upgrade.
LSC: go/checker-lsc
Tested:
TAP train for global presubmit queue
http://test/OCL:342788973:BASE:342817196:1605636478036:6c558c0c
***
PiperOrigin-RevId: 343895651
*** Original commit ***
Suppress warnings in preparation for Checker Framework 3.7.1 upgrade.
LSC: go/checker-lsc
Tested:
tap_presubmit: http://test/OCL:342788975:BASE:342885903:1605667635149:7731b723
Some tests failed; test failures are believed to be unrelated to this CL
***
PiperOrigin-RevId: 343251530
The 'implementation' dependency causes problems when resolving
ListenableFuture in contexts that also include the
com.google.guava:listenablefuture:1.0 dependency.
Issue: #7905
Issue: #7997
Issue: #7993
PiperOrigin-RevId: 337093024
When I moved ParsableByteArray#data behind a getter I replaced some
assignments with calls to reset(byte[]):
ce2e6e2fd6
reset(byte[]) deliberately sets `limit` to `data.length`, in order to
handle cases that were reassigning `data` but not updating `limit`.
However OggPacket was already using `limit` to track where to write
'new' data into the array, so changing `limit` to `data.length` caused
us to try and write new data beyond the end of the array.
I looked at other uses of reset(byte[]) in ce2e6e2fd6
and condluded the only other usage in MatroskaExtractor is legit and
shouldn't be updated like this (because MatroskaExtractor previously
*wasn't* correctly updating/maintaining `limit`).
Issue: #7992
PiperOrigin-RevId: 334601586
This seems to be an exact copy of sample.adts. Update the test to use
the same sample but just output to a different dump file.
PiperOrigin-RevId: 333469714
This allows to customize extractor flags more easily when setting up the player.
In addition, we need to provide a way to pass in the ExtractorFactory through
the constructor chain starting in SimpleExoPlayer so that removing the
DefaultExtractorsFactory is possible for R8.
PiperOrigin-RevId: 330472935
This allows us to more easily create different dumps derived from the
same assets.
This moves media/source files from `assets/` to `assets/media/` and
dump files from `assets/` to `assets/extractordumps/` and
`assets/audiosinkdumps/` as appropriate. I intend to add
`assets/playbackdumps/` in a future CL.
PiperOrigin-RevId: 326986283
Find sbgp and sgpd boxes with grouping_type == seig in the case they don't
come first. Previoulsy we would only find them if they came first.
Issue: Issue: #7716
PiperOrigin-RevId: 325407819
