For when a track is both encrypted and has supplemental data, the sample size will be equal to `block sample size - encryption data size`.
PiperOrigin-RevId: 427807612
When a asset contains multiple cc embedded tracks, current Cea708Decoder service
block parsing logic is discarding all the data in that frame.
For example, a manifest with 2 embedded CEA-708 close captions tracks:
<Accessibility schemeIdUri="urn:scte:dash:cc:cea-708:2015" value="1=lang:eng;2=lang:spa"/>
when the spanish track is selected (service number 2), when processing the
following CEA-708 frame:
FC9420FD2062FF0829FE8CFCFE9818FEE332FE731FFE1042FE2062FE0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000
the frame can be descomposed as:
FF0829 FE8CFC FE9818 FEE332 FE731F FE1042 FE2062 FE0000
08 (00 001000) 0 (sequence) 8 (frame size)
298CFC9818E332731F10 422062 0000
=====
29 (001 01001) 1 (service number) 9 (service block length)
8CFC9818E332731F10
42 (010 00010) 2 (service number) 2 (service block length)
2062
0000 Null block service
The current processCurrentPacket logic will discard the whole frame is discarded
because the first service number found in the frame belongs to service number 1,
which is not the one we are currently looking for.
This commit modifies the processCurrentPacket decoding logic, to take into
account all service blocks available in the frame, by iteraring over the
full frame data and skipping those service blocks we are not interesting in.
Signed-off-by: Jorge Ruesga <jorge@ruesga.com>
This is a breaking change if the annotation itself is in use in Kotlin
code. It's judged that the IntDefs in this commit are unlikely to be
referred to often in Kotlin code. This is because they're either:
- Related to esoteric parts of the library, or
- In a common part of the library but only returned from methods (and
never passed to callback methods).
A follow-up change will fix the positions of existing usages to match
this new config.
#minor-release
PiperOrigin-RevId: 426410237
This only changes IntDefs that cannot be used by apps because they're
either private or package-private.
A follow-up change will fix the positions of existing usages to match
this new config.
#minor-release
PiperOrigin-RevId: 426372273
The longer list of targets is only necessary for backwards
compatibility with existing Kotlin code that will stop compiling
if the position of the annotation becomes 'wrong' by marking it only
TYPE_USE. Since none of these IntDefs have been released (except in
media3 alpha1) we don't need to maintain this compatibility.
Also add a comment to all the places that *do* need the longer list of
targets, in order to explain why it's there and discourage copy-pasting
when defining new IntDefs in future.
Also fix some single-element arrays to remove the array notation.
#minor-release
PiperOrigin-RevId: 426108537
The current implementation of ExoPlayer Cea708 is processing the whole service block without
taking into account the defined service block size, which could cause the execution of
unwanted command.
The following set of Cea708 represents a real use case of the above.
``` hex
FC9420FD152FFF0929FE8CFCFE9818FEE332FE731FFE1044FE8B03FE8CFCFE0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000
FC942CFD1520FF4649FE8CFEFE9918FEE332FE731FFE1000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000
FC942FFD9470FF8924FE8B03FE8CFCFE4A92FE0300FE9005FE0091FE2A00FE0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000
FC9420FD97A1FFC829FE8CFEFE9918FEE332FE731FFE1043FE9203FE0100FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000
FC94D6FDCEEFFF082AFE9202FE0C90FE0500FE912AFE0000FE424EFE6F00FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000
FCC168FD20F4FF4422FE4168FE4220FE7400FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000
FC2C20FDE520FF8422FE2C20FE4265FE2000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000
FC64EFFD70EFFFC422FE646FFE4270FE6F00FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000
FC6EA7FD6E67FF0422FE6E27FE426EFE6700FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000
FCF420FD6173FF4422FE7420FE4261FE7300FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000
FC67E5FD206DFF8422FE6765FE4220FE6D00FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000
FCF480FD7579FFC422FE7403FE4275FE7900FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000
```
The above frames should be displaying the following text on the screen (or at least the first part of it).
```
Ah, don't get
all sappy about it
```
ExoPlayer is currently parsing this block as follow (in parentheses the defined service block size):
```
(2) 22416842207400
G0 A
G0 h
G0 B
G0 \u0020
G0 t
C0 COMMAND_NUL
(2) 222C2042652000
G0 ,
G0 \u0020
G0 B
G0 e
G0 \u0020
C0 COMMAND_NUL
(2) 22646F42706F00
G0 d
G0 o
G0 B
G0 p
G0 o
C0 COMMAND_NUL
(2) 226E27426E6700
G0 n
G0 '
G0 B
G0 n
G0 g
C0 COMMAND_NUL
(2) 22742042617300
G0 t
G0 \u0020
G0 B
G0 a
G0 s
C0 COMMAND_NUL
(2) 22676542206D00
G0 g
G0 e
G0 B
G0 \u0020
G0 m
C0 COMMAND_NUL
(2) 22740342757900
G0 t
C0 COMMAND_ETX
G0 B
G0 u
G0 y
C0 COMMAND_NUL
(2) 2392030C4220730000
C1 COMMAND_SPL
G0 B
G0 \u0020
G0 s
C0 COMMAND_NUL
C0 COMMAND_NUL
(2) 22616C42656E00
G0 a
G0 l
G0 B
G0 e
G0 n
C0 COMMAND_NUL
```
So it ended up processing the following cue text (additional unwanted commands could be executed as well)
```
AhB t, Be doBpon'Bngt BasgeB mt
BuyB salBen
```
If instead the parsing logic take into account the service block size
```
(2) 22416842207400
G0 A
G0 h
(2) 222C2042652000
G0 ,
G0 \u0020
(2) 22646F42706F00
G0 d
G0 o
(2) 226E27426E6700
G0 n
G0 '
(2) 22742042617300
G0 t
G0 \u0020
(2) 22676542206D00
G0 g
G0 e
(2) 22740342757900
G0 t
C0 COMMAND_ETX
(2) 2392030C4220730000
C1 COMMAND_SPL
(2) 22616C42656E00
G0 a
G0 l
```
which is translated to (again I didn't processed all the frames, just a few of them)
```
Ah, don't get
al
```
which is what we are looking for.
This PR modifies service block parsing logic to honor service block size instead of read the full service block buffer.
Signed-off-by: Jorge Ruesga <jorge@ruesga.com>
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
