- 13 Feb, 2020 15 commits
-
-
This information isn't easily available to the player at the moment (or it would need to revaluate this every time), so add it to MediaPeriodInfo similar to the existing isLastInTimelinePeriod. The player needs to know whether a MediaPeriod is the last in its Timeline window if we want to add an option to pause at the end of a window. PiperOrigin-RevId: 294877628
tonihei committed -
PiperOrigin-RevId: 294689274
andrewlewis committed -
Add fields in DecoderCounters for computing the average video frame processing offset. The MediaCodecVideoRenderer reports the video frame processing offset and the demo app presents it on the debug information. PiperOrigin-RevId: 294677878
christosts committed -
The transition in EPII happens based on the duration of the periods, not the windows. So use this duration in case they are not the same. Also make sure to send the message at duration-1 because the playback position at the duration is technically already the first position in the next item. PiperOrigin-RevId: 294669335
tonihei committed -
Issue: #2863 PiperOrigin-RevId: 294661214
olly committed -
This simplifies sending messages to the end of a stream. This was already possible, but users needed to wait until the duration is known before sending the message. This duration resolution can happen as part of the message position resolution. PiperOrigin-RevId: 294626984
tonihei committed -
PiperOrigin-RevId: 294621946
kimvde committed -
This is a no-op change and just moves some duplicated logic into the base class. PiperOrigin-RevId: 294615218
tonihei committed -
PiperOrigin-RevId: 294614958
kimvde committed -
PiperOrigin-RevId: 294613898
kimvde committed -
- Removes empty <p> tag in javadoc - Removes incorrect parameter name warnings for var args. PiperOrigin-RevId: 294555651
olly committed -
Issue: #2863 PiperOrigin-RevId: 294531127
olly committed -
Keeping (Uri) and (Uri, position, length) to avoid needing Builder for the trivial case. PiperOrigin-RevId: 294530226
olly committed -
PiperOrigin-RevId: 294520836
olly committed -
PiperOrigin-RevId: 294518763
olly committed
-
- 11 Feb, 2020 25 commits
-
-
PiperOrigin-RevId: 294503035
olly committed -
Language is already applicable to image formats as well. It can also apply to video formats. For example when the video contains burnt in subtitles. Also, some animation studios produce multiple variants of animations, in which text within the scene itself (e.g., a signpost) is replaced to be language specific. PiperOrigin-RevId: 294500227
olly committed -
- Replace tests specific to HTTP request headers with tests that more generally test constructor correctness. - Add test specifically around the constructor that infers the HTTP method from postBody, since that's a non-trivial bit of constructor logic. Note: In general, I'm not sure this type of test (i.e., testing a bit of trivial copying through a constructor) is worth the cost of writing and maintaining them. That said, checking the new uriPositionOffset is calculated correctly is non-trivial, as is the HTTP method inference, so keeping them for now. PiperOrigin-RevId: 294488684
olly committed -
This is a preliminary step toward adding a DataSpec.Builder, which is needed for sanity when adding DataSpec.customData. The existing absoluteStreamPosition field is very error prone, because anyone using a Builder to adjust the request position will need to remember to adjust two values: dataSpec .buildUpon() .setAbsoluteStreamPosition(x) .setPosition(x) .build(); Furthermore, the difference between position and absoluteStreamPosition is irrelevant in nearly all cases. In the core library, the difference is only relevant when initializing AES encryption/decryption to write/read cache files. Replacing absoluteStreamPosition with uriPositionOffset will simplify the code block above to: dataSpec .buildUpon() .setPosition(x) .build(); PiperOrigin-RevId: 294485644olly committed -
PiperOrigin-RevId: 294465827
kimvde committed -
PiperOrigin-RevId: 294441610
kim-vde committed -
Replace Thread with thread on documentation. PiperOrigin-RevId: 294401357
christosts committed -
Add support for asynchronous input buffer queueing in the MultiLockAsyncMediaCodecAdapter. PiperOrigin-RevId: 294397811
christosts committed -
- Add method to scale scrubber handle of DefaultTimeBar PiperOrigin-RevId: 294366734
olly committed -
PiperOrigin-RevId: 294241169
kimvde committed -
PiperOrigin-RevId: 294239472
kimvde committed -
Currently, the subset of audio tracks for adaptation is selected purely based on the size of the subset in the track group, completely ignoring the previously selected best individual track. This change ignores all tracks with a different configuration than the previously selected best track. PiperOrigin-RevId: 294231806
tonihei committed -
PiperOrigin-RevId: 294222083
bachinger committed -
The DedicatedThreadAsyncMediaCodecAdapter supports enqueueing input buffers in a background Thread. PiperOrigin-RevId: 294202744
christosts committed -
PiperOrigin-RevId: 294193213
aquilescanta committed -
Issue: #6951 PiperOrigin-RevId: 294187695
aquilescanta committed -
PiperOrigin-RevId: 294184891
kimvde committed -
PiperOrigin-RevId: 294183213
olly committed -
PiperOrigin-RevId: 294182858
bachinger committed -
MediaCodecInputBufferEnqueuer wraps MediaCodec queue operations. PiperOrigin-RevId: 294182717
christosts committed -
PiperOrigin-RevId: 294181886
bachinger committed -
PiperOrigin-RevId: 294179427
andrewlewis committed -
PiperOrigin-RevId: 294074348
bachinger committed -
This allows the file to be created automatically when FakeExtractorOutput#WRITE_DUMP is true. PiperOrigin-RevId: 293834547
kimvde committed -
static_cast is more appropriate than reinrerpret_cast for casting from void* to JniContext*. See Section 7.2.1 (page 173) in The C++ Programming Language, 4th Edition and https://stackoverflow.com/questions/310451/should-i-use-static-cast-or-reinterpret-cast-when-casting-a-void-to-whatever PiperOrigin-RevId: 293812940
olly committed
-