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
Video renderers assume that the player position is advancing linearly while in
the started state. MediaCodecVideoRenderer schedules frames for rendering in the
future in the expectation that the player position is advancing.
This assumption is not currently true when using a position from the AudioTrack:
the player position can be fixed for (in the worst case) up to about 100 ms
before it starts increasing. This leads to an effect where the first frame is
rendered then a few other frames are rendered, then there's a pause before
frames start being rendered smoothly.
Work around this issue by checking whether the position has started advancing
before scheduling frames to be rendered in the future.
It might be preferable to make the audio renderer only become ready when its
timestamp can start advancing, but this is likely to be complicated.
Issue: #3841
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190937429
In audio processors an audio frame consists of a sample (which is 2 bytes for
16-bit PCM) for each channel. Sonic used "sample" to refer to this.
We've already diverged from the original source for Sonic quite a bit (deleting
code and making stylistic changes) and there haven't been upstream changes so
far, so it seems fine to start making more substantial changes here.
There should be no behavior changes here.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190916793
In Gradle 4.4, it is a bug to resolve a configuration before the lint task is
created ([see [] Therefore, to upgrade
gradle version, we need to change the "generateJavadoc" task to remove using
files() call during initialization phase, but change move this to doFirst()
instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190634090
Currently, we are treating all codecs starting with "mp4a" as AAC. However,
some codec strings starting with "mp4a" are not AAC format, as should be
treated differently.
GitHub: #3779
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=189163517
Use string concatenation for Metadata.Entry instances, and add
Util.formatInvariant for numerical formatting.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190915643
This adds two options to the ClippingMediaSource which allow proper clipping
of live streams:
1. The clipping stays fixed relative to already created media periods. That
means that playback actually progresses through the clipped media and
eventually reaches the end of the clipping. The window is also marked
as non-dynamic to let playback end in this case.
2. Allow to specify a clipping duration relative to the default position to
be able to specify the duration of live stream which is to be played.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190911049
*** Reason for rollback ***
b/76391022 was caused by a timestamp correction in StabilizableSimpleExoPlayer which will be fixed with this CL.
*** Original change description ***
Automated g4 rollback of changelist 189570277.
*** Reason for rollback ***
causes b/76391022, motion still playback in Photos is broken
*** Original change description ***
Used fixed time frame in clipping media period.
Currently, whenever the clipping is updated, we move the time frame of the
clipped period to start at 0. This causes problems when we are already playing
this period and the renderer position does no longer match the stream
positions.
This change keeps the time frame of the...
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190906020
- Ensure that no memory is used by audio processors that are always inactive, by
only allocating in flush() if active. If data was already allocated but a
processor becomes inactive we assume that the allocation may be needed in
future so do not remove it (e.g., in the case of ResamplingAudioProcessor).
- Make SilenceSkippingAudioProcessor set up its buffers in flush(), and clarify
that it is always necessary to call flush() if configure() returns true.
- Make reset() reset all state for all processors.
- Use @Nullable state or empty arrays for inactive audio processor buffers.
- Miscellaneous style/consistency cleanup.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190895783
A merge error in a previous change removed the drmSessionManager from
the player factory call.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190769364
In some situations, the timeline can't be specified because it is created
internally by the media source under test. If the test still needs to wait for
a timeline update, this change allows to do that by specifying an expected
timeline of null.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190768386
Doing that in the current order may result in cases where we have a player
instance but a null media source and thus the next call to initializePlayer
will fail.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190765633
