Also refactor the tests to make them behavioral (rather than testing the method)
and inline simple assertions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191867614
These don't seem to be needed anymore. All tests run without them in gradle
and Blaze.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191867518
In MatroskaExtractor TrueHD audio samples are joined into larger chunks. For
some streams the resulting chunked samples seem never to start with a syncframe.
This could result in playback of TrueHD streams getting stuck after seeking
because we could never read a syncframe at the start of a sample to determine
the sample size.
Instead of expecting to find a syncframe at the start of a sample, search for it
within the sample, to fix this issue.
Note: this means that we may search a few thousand bytes to find the sample
size, but the cost is only incurred for the first audio sample read.
Issue: #3845
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191775779
This field (formerly "id") is almost impossible to use so far. Having setters
in the factories allows to specify custom tags for all media sources.
Also added a ExoPlayer.getCurrentTag() method to retrieve the tag of the
currently playing media source in a convenient way.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191738754
The data collector keeps track of active media periods to assign each event to
the correct media period and/or window. This information, together with other
information like playback position and buffered duration, is then forwarded
with the event to all registered listeners.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191726408
Previously the SonicAudioProcessor and SilenceSkippingAudioProcessor would track
their pending playback parameters and only apply them in flush(). Having the
values only take effect once flushed made the processors a bit more difficult to
use, especially because the value returned by isActive wouldn't update
immediately.
Make DefaultAudioSink only set the new speed/pitch/skip silence setting after
the audio processors have drained. This means it's no longer necessary to keep
track of pending parameter values and also fixes a bug where initial playback
parameters weren't applied because the audio processors weren't flushed while
uninitialized before DefaultAudioSink called isActive() on them.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191586727
The previous API allowed to pass in null to the constructors although variants
without listeners exist. That's why we need to handle these null values.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191577891
Partial rollback of [] which caused b/77294898 by deleting a public Exoplayer API.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191519591
- Upgrade to latest version
- Use api dependency, since application code that uses the
extension more has to use OkHttp directly to make an
OkHttpClient instance
- Add proguard configuration
Issue #4059
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191422594
Previously it was necessary to create a new Sonic instance every time the
processor was flushed. Add a flush() method to Sonic so that it can be reused
when seeking. It still needs to be recreated when parameters change.
SonicAudioProcessor and SilenceSkippingAudioProcessor have methods for setting
parameters that are documented as taking effect after a call to flush(), but
actually the value returned by isActive() was updated immediately. Track the
pending values and apply them in flush() to fix this.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191442336
- Upgrade to latest version
- Use api dependency, since application code that uses the
extension more has to use OkHttp directly to make an
OkHttpClient instance
- Add proguard configuration
Issue #4059
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191422594
We currently refresh repeatedly in this case. According to the
DASH spec omitting minUpdatePeriod indicates that the manifest
does not change, and therefore we should not refresh. I think
it might be valid to omit minUpdatePeriod in a dynamic manifest
if relying exclusively on EMSGs to trigger manifest refresh.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191420247
applyContentMetadataMutations and getContentMetadata methods suppossed to be synchronized and assert the instance isn't released.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191419637
This is in preparation for making it possible to flush a Sonic instance so that
it's not necessary to create new ones every time the processor is flushed.
There should be no behavior changes here.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191410326
To be immediately rolled back after submission
Submitting on behalf of cblay.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191128111
- Remove stray extra "/" from postprocessed oracle URLs
- Remove date lines so the Javadoc diff better shows what
actually changed between releases
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190973079
- Remove stray extra "/" from postprocessed oracle URLs
- Remove date lines so the Javadoc diff better shows what
actually changed between releases
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190973079
Weirdly, the Android Javadoc indicates that it returns something
before the API level on which the same Javadoc states it was added.
In any case, we can simply not call the method to avoid the
warning, since we only use the value if the API level is at least
23 anyway.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190941776
Weirdly, the Android Javadoc indicates that it returns something
before the API level on which the same Javadoc states it was added.
In any case, we can simply not call the method to avoid the
warning, since we only use the value if the API level is at least
23 anyway.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190941776
