This check is not needed because the FLAC specification does not
restrict the sample rate value and because the extension reads files
with other sample rates properly.
PiperOrigin-RevId: 292909391
This condition is trying to detect when it might be necessary
to switch from a non-secure to a secure codec. This is not
possible if the DRM session is unchanged, unless a different
codec is required for some other reason (e.g., H264 -> H265),
which is anyway handled by canKeepCodec below.
PiperOrigin-RevId: 292909126
Passing EXT-X-KEY DrmInitData through the FragmentedMp4Extractor
doesn't work for streams with key rotation, because an extractor
instance is used for multiple segments, but is only passed the
EXT-X-KEY DrmInitData corresponding to the first segment.
This change removes passing DrmInitData through the extractor,
and instead passes it via FormatAdjustingSampleQueue. This is
in-line with how manifest DrmInitData is handled during DASH
playbacks.
Issue: #6903
PiperOrigin-RevId: 292323429
This is a nice-regardless improvement to SampleQueue, which will
likely to used to fix the referenced issue. It makes it possible
for SampleQueue subclasses to support dynamic changes to format
adjustment in a non-hacky way.
Issue: #6903
PiperOrigin-RevId: 292314720
It doesn't seem worth keeping the cap, since the device
will presumably stop receiving major version updates at
some point anyway.
Issue: #6899
PiperOrigin-RevId: 291899439
Currently we only do this for the main sample URI, not for subtitles.
So pairing a web-based video file with a local subtitle file on a fresh
install just throws a 'permission denied' exception.
PiperOrigin-RevId: 290794091
+ force arm (over thumb) mode for 32-bit builds
-O2 improves performance ~30-40% over the default -Oz depending on the
resolution; this is similar to what is done for vp9 which uses -O3.
PiperOrigin-RevId: 290318121
- Add additional Listener methods to DownloadManager, to inform of
changes to whether the downloads are paused or waiting for requirements.
- Only schedule the Scheduler if we really are waiting for requirements.
- Only restart the service if we're no longer waiting for requirements,
and if there are queued downloads that will now be restarted.
Previously the service would be restarted whenever the requirements
were met, regardless of whether there was any work to do.
- Restart service if it might be stopping, as well as if it's already
stopped. Also restart service if there's a download state change to a
state for which the service should be started, if.
Issue: #6798
PiperOrigin-RevId: 290270547
Doing so prevent Codec which is a big object with
JNI to be garbage collected.
As the codec can not be hold in the listener, there
is no way to call release, as it must be called on
the same codec.
As a result the release method is also removed.
The downside is that at runtime some callbacks may be
dropped but it should be a short transitive state.
This also simplifies lifecycle of the listener as
the client does not have to know if release needs
to be called or not.
An alternative would have been to hold a weak ref,
but I deemed it too complicated for the
runtime gain.
PiperOrigin-RevId: 290231659
This fixes an issue where a DownloadService implementation
that allows foreground but doesn't provide a scheduler would
not be restarted in the case that it was still in memory but
classed as idle by the platform.
It also speeds up service restart in the case that a
scheduler is provided.
Issue: #6798
PiperOrigin-RevId: 290068960
This method has two use cases:
1. Seeking. Calls are immediately preceded by a call to rewind(), and
the returned value isn't important unless it's ADVANCED_FAILED (i.e.
the caller is only interested in success and failure).
2. Advancing. The return value is important unless it's ADVANCED_FAILED,
in which case the caller wants to treat it as 0.
This change creates separate methods for each use case. The new seekTo
methods automatically rewind and return a boolean. The updated advanceTo
method returns 0 directly in cases where ADVANCED_FAILED was returned.
Arguments that were always hard-coded to true by callers have also been
removed.
This change is a step toward one possible solution for #6155. How we'll
solve that issue is still up for discussion, but this change seems like
one we should make regardless!
Issue: #6155
PiperOrigin-RevId: 290053743
- DownloadManagerHelper now passes all downloads to the
DownloadService when the service is attached (and once
the downloads are known). The service then starts the
foreground notification updater if necessary. This fixes
the ref'd issue.
- Don't call getScheduler() if the service is background
only. This was already documented to be the case on the
DownloadService constructor.
- If the service is started in the foreground on SDK level
26 and higher, satisfy the condition to move the service
to the foreground in onStartCommand rather than in stop().
It's much more obviously correct, and should produce the
same end result.
Issue: #6798
PiperOrigin-RevId: 290050024
This optimization allows a ChunkSampleStream to output track
formats as soon as they're parsed during an InitializationChunk
load, rather than waiting until after the InitializationChunk
load is completed.
In DASH VOD, a single InitializationChunk typically loads the
moov and sidx atoms in that order. Hence for long form content
where the sidx is a non-trivial size, this may result in the
track formats being output a non-negligible period of time
sooner than was previously the case. This allows downstream
renderers to start codec initialization sooner, potentially
decreasing startup latency.
For a single test stream on a fast & stable network, this
pretty consistently reduced elapsed time until both audio and
video codecs have been initialized from ~0.5s to ~0.3 seconds
on a Galaxy S8. For 5 test runs without and with these patches,
the eventTime logged by EventLogger for the second decoder
init were:
Without (secs): 0.47 0.47 0.45 0.48 0.46
With (secs) : 0.32 0.33 0.34 0.31 0.40
PiperOrigin-RevId: 289845089
The current order of operations means that the Format is only passed
to the chunk's output after the DataSource has been opened. This
means that establishing the network connection and the downstream
renderers initializing their codecs are effectively serialized to
occur one after the other.
In the new order, the Format is passed to the chunk's output before
the DataSource has been opened. This allows the downstream renderers
to initialize their codecs in parallel with the network connection
being established, and hence latency at the start of playback is
reduced.
PiperOrigin-RevId: 289841854
As discovered whilst investigating #6798, there are cases
where these methods are not correctly. They were added as
convenience methods that could be overridden by concrete
DownloadService implementations, but since they don't work
properly it's preferable to require application code to
listen to their DownloadManager directly instead.
Notes:
- The original proposal to fix#6798 stored the state change
events in memory until they could be delivered. This approach
is not ideal because the events still end up being delivered
later than they should be. We also want to fix the root cause
in a different way that does not require doing this.
- This change does not fix#6798. It's a preparatory step.
Issue: #6798
PiperOrigin-RevId: 289418555
This change makes it clear the SampleQueue doesn't outlive
the wrapping PlayerTrackEmsgHandler, and releases it from
PlayerTrackEmsgHandler.release().
This change is a no-op because calling release() is the
same as reset() in this case (the behavior only differs if
a non-dummy DrmSessionManager is being used).
PiperOrigin-RevId: 289416622
As a result, onMediaChunkLoadStarted gets invoked on the loading thread, and
init on the playback thread, matching the thread access comments.
Issue:#6321
PiperOrigin-RevId: 289167981
Unfortunately devices such as the MI 8 do not provide an alternative
working decoder. Some Vivo devices do provide one though.
PiperOrigin-RevId: 288911897
