Format expects the values of `averageBitrate` and `peakBitrate` in bps and the value fetched from AC3SpecificBox and EC3SpecificBox is in kbps.
PiperOrigin-RevId: 490756581
(cherry picked from commit 67955e0ce331481bcb3fd94c9ffb9632f27eae6e)
To avoid complicated bit shifting and masking. Also makes the code more readable.
PiperOrigin-RevId: 490749482
(cherry picked from commit 89e4b8d049507efeb610f437429f25cf18df8f8b)
*** Original commit ***
Rollback of 01eddb34f5
*** Original commit ***
Parse and set `peakBitrate` for Dolby TrueHD(AC-3) and (E-)AC-3
#minor-release
***
***
PiperOrigin-RevId: 490707234
(cherry picked from commit 8c91a31ced401ce14911fbfdf58dda3c7ee8e643)
*** Original commit ***
Parse and set `peakBitrate` for Dolby TrueHD(AC-3) and (E-)AC-3
#minor-release
***
PiperOrigin-RevId: 490570517
(cherry picked from commit ea3552c1a030d8b14c0cd0093f7eaa6242f969eb)
ExoPlayer is unable to detect the presence of subtitle tracks in some
MPEG-TS files that don't fully declare them. It's possible for a
developer to provide the list instead, but doing so is quite awkward
without this helper method. This is consistent for how
`DefaultExtractorsFactory` allows other aspects of the delegate
`Extractor` implementations to be customised.
* Issue: google/ExoPlayer#10175
* Issue: google/ExoPlayer#10505
#minor-release
PiperOrigin-RevId: 490214619
(cherry picked from commit 4853444f0dc90163c257d0e20962604510557df4)
If there's an @param javadoc tag in a supertype then all overrides
of this method that don't also override the javadoc must use the same
parameter name.
PiperOrigin-RevId: 485857711
(cherry picked from commit b8e5d708fc77a06e831abd7f2c2e57f68bb3720f)
From ANSI-CTA-608-E R-2014 section 8.4:
> When closed captioning is used on line 21, field 2, it shall conform
> to all of the applicable specifications and recommended practices as
> defined for field 1 services with the following differences:
> 1. The non-printing character of the miscellaneous control-character
> pairs that fall in the range of 0x14, 0x20 to 0x14, 0x2F in field 1,
> shall be replaced with 0x15, 0x20 to 0x15, 0x2F when used in field
> 2.
> 2. The non-printing character of the miscellaneous control-character
> pairs that fall in the range of 0x1C, 0x20 to 0x1C, 0x2F in field
> 1, shall be replaced with 0x1D, 0x20 to 0x1D, 0x2F when used in
> field 2.
This basically means that `cc1=0x15` in field 2 should be interpreted as
`cc1=0x14` in field 1, and same for `0x1D -> 0x1C`.
The `isMiscCode` method above already handles this by ignoring the LSB
(the only difference between `0x14` and `0x15`, and `0x1C` and `0x1D`)
by AND-ing with `0xF6` instead of `0xF7`. This change uses the same
trick in `isServiceSwitchCommand`.
Issue: google/ExoPlayer#10666
#minor-release
PiperOrigin-RevId: 483927506
(cherry picked from commit 7c6d492ff19b6aead4cc6f1f9a426145fc1faa0d)
This is a no-op, but it's more 'correct' because it avoids any potential
sign mix-ups that come from storing an unsigned byte (with a
potentially set MSB) in a signed java byte variable.
PiperOrigin-RevId: 483409798
(cherry picked from commit 3d0f43a149c846670480c993e09def1a2d2eeeea)
When debugging and fixing Issue: google/ExoPlayer#10666 I wanted to write a regression
test, but needed to add a test first... This is just a small bit of
coverage to start with. It checks the field/channel filtering works
correctly, but doesn't check any styling info. It also doesn't test
'pop on' subtitles (i.e. when the subtitle isn't shown until a 'end of
subtitle' signal is received).
PiperOrigin-RevId: 480644568
(cherry picked from commit 6052212c15b89d71846f1f3855728ce863304bca)
It's always safe to ignore the result of these methods, because the
caller already has a reference to the returned value.
PiperOrigin-RevId: 462388947
(cherry picked from commit 21cab6124de7b65f1af016cfc260555fa0b6e738)
`HevcConfig.parse` misreads reserved bit to determine NAL unit type. This is currently meant to be always set to 0, but could be given some kind of meaning in a future revision.
Issue: google/ExoPlayer#10366
PiperOrigin-RevId: 460487613
(cherry picked from commit 0f665fbeb8fca52853ab5dd0a8030484e50402dd)
As per MP4 spec, bitrates in esds boxes can be a 32 bit number which doesn't fits in Java int type, so now reading it as a long value. Our class for holding media format, only allows bitrates value to be an int as we don't expect the bitrates to be greater than or equal to 2^31. So we're limiting the values for bitrates to Integer.MAX_VALUE.
#minor-release
PiperOrigin-RevId: 458423162
(cherry picked from commit 9e10286b5ea624b8a7533e5fc452b19476589764)
As per MP4 spec, the length of URL array is a 8 bit number.
#minor-release
PiperOrigin-RevId: 458421436
(cherry picked from commit 5095ff160bec2fdad21a51351373a03073236ffd)
This reinstates the permissive behaviour removed by
fe7e5b8181
Test file created by opening bear.opus in a hex editor and naively
duplicating the two header packets, starting at (and including) the
first `OggS` in the file and ending just before the third `OggS`.
#minor-release
Issue: google/ExoPlayer#10038
PiperOrigin-RevId: 452015662
(cherry picked from commit b6b282672c45263d0f9e2b6ece4f6de1083812cb)
We add an entire class like we do for parsing other codec initialization formats; it's currently not doing any parsing though (... initialization data is really simple for AV1 though: just the entire contents of the box).
For testing, we add the sample file, having been re-encoded with ffmpeg (and we also happen to have another av1 file, too).
PiperOrigin-RevId: 444890282
We add an entire class like we do for parsing other codec initialization formats; it's currently not doing any parsing though (... initialization data is really simple for AV1 though: just the entire contents of the box).
For testing, we add the sample file, having been re-encoded with ffmpeg (and we also happen to have another av1 file, too).
PiperOrigin-RevId: 439453823
This provides better compatibility with MediaExtractor, which does read these fields; we also need them for being able to mux file contents into another mp4 file.
Also, there is a minor refactor included so that we have an actual type for esds box contents instead of a pair.
PiperOrigin-RevId: 438673825
OutlineColour should be treated as the background color if BorderStyle=3. Since currently BorderStyle is ignored, we can always treat OutlineColor as the background color.
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
