A remove action will eventually just be the unique ID of the download
that should be removed. This is a step toward that goal.
PiperOrigin-RevId: 222832456
[Problem]
PAINT-ON mode is not implemented. From the compliance tests:
* RDC command has no effect except to select paint-on style.
* Next data are written directly to the display upon receipt.
* If other captioning is already on the screen, the four-row
limit is still in effect.
[Solution]
It is a rare use case, we do not support overriding characters in
existing cueBuilders as PAINT-ON would require. But several
compliance tests check if the screen is cleared when the mode
switch happens. We must keep the old captions when switching
to PAINT-ON mode
[Test]
- Live Over-the-Air content, beginning of commercials often uses
PAINT-ON mode
- Add DownloadAction.fromByteArray for symmetry with toByteArray
- Make DownloadService call fromByteArray, for symmetry with calls
to toByteArray
PiperOrigin-RevId: 222801703
We already have tests for comment blocks, and they already
pass because we discard the comment when we fail to parse it
as a cue. We should just skip it directly, however.
The input.getLength() check is invalid because the length may be
unknown (i.e. if the server doesn't include a Content-Length
response header when serving chunks).
Issue: #5063 (tangentially related only)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222406347
This allows more efficient range removals and is consistent with addition,
which supports adding multiple elements in a single operation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222396310
This allows to account for bandwidth used by fixed track selections.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222383736
BandwidthProvider allows bandwidth allocation logic to be customized.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222293581
1. Pull up all subclasses of DownloadAction into DownloadAction
2. Add DownloaderFactory for Downloader instantiation, and DefaultDownloaderFactory
to replace the instantiation logic being removed from the DownloadAction
subclasses.
This change will upgrade existing action files gracefully (i.e. it does not
lose compatibility with the existing offline implementation, other than some
minor breaking changes to the API).
TODOs:
1. Move test methods from the XDownloadActionTest classes into DownloadActionTest.
This will be done in a subsequent CL. There's a lot of consolidation that can
be done here, including de-duplicating some of the test code added in this CL.
2. Look at merging DownloaderConstructorHelper into DefaultDownloaderFactory.
3. Use customCacheKey in DASH/HLS/SS Downloaders, for completeness.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222258983
createTrackSelections decides whether to create an adaptive or a fixed track seletion to create.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222231011
Forwarding the listeners to the notification update is meant to ensure we
only notify the listeners which were registered at the time the event happened
However, we currently just copy the reference to the actual list instead of
doing a deep copy of the listeners.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222227735
This ensures that all callbacks use the same notification mechanism.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222226913
The update is actually unrelated and putting it all in one large update
object complicates adding the same update mechanism for other values.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222226825
WindowedTrackBitrateEstimator, uses future and past chunks in a window
of time to estimate track bitrate values.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222065409
Currently no path may be chosen if
minBufferUs == maxBufferUs == bufferedDurationUs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221639199
This is needed because the allocator can't be reused for example.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221638233
- Increase the search window size to fix TS seeking for problematic
media we've had provided to us.
- As per my comments on the issue, we should look at doing more here
to better fix the problem. This will solve the worst of the
immediate problem, however.
- The memory usage is non-trivial, particularly with the increased
search window size. I've made the allocations only live whilst
determining duration and seeking to address this. I've done the same
for PS just for consistency.
Issue: #5097
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221449988
The remaining work is to split Window.isDynamic so that it's
possible to represent a window that wont be appended to, but
may still be removed from.
Issue: #4780
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221439220
This is a precursor for fixing the ref'd issue. These classes are
well tested, so the tests passing should give you reasonable
confidence I didn't break anything :).
Issue: #5097
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221435824
LegacyVideoTrackSelection is the previous implementation (unchanged).
VideoTrackSelection is rewritten to extend AdaptiveTrackSelection.
An experiment is added to allow use of the new VideoTrackSelection
implementation. It's envisaged that this transition will be more or
less a no-op change. The experiment flag is only in case of bugs
during roll-out, and will be removed with LegacyVideoTrackSelection
upon successful transition.
VideoTrackSelection also implements discard-on-trick-play-exit, which
was a TODO in the previous implementation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221153827
- This brings it in line with PlayerControlView. The play action is displayed
instead, and pressing it seeks to the default position of the current window.
- Do the same for MediaSessionConnector
- Add support for PlaybackPreparer consistent with PlayerControlView
Issue: #5072
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221076008
This change also paves the way for splitting out functionality into a utility class.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221070262
When in REPEAT_MODE_ONE, it's unlikely apps want next/previous methods
on the player to keep them in the same window. Music apps in particular
tend to implement next/previous functionality as though repeat mode were
off when in this mode (i.e. current song loops forever during playback,
but next/previous navigation still navigates to next/previous items).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220469655
This fixes an issue where disabling audio focus handling
while audio focus is held would not release audio focus.
A new test was added for this situation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220316866
*** Reason for rollback ***
Rolling forward again as [] should fix issue that prompted the rollback
*** Original change description ***
Automated g4 rollback of changelist 219130576.
*** Original change description ***
Re-enable codec re-use
Issue: #2826
***
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220124362
It's no longer guaranteed that onOutputFormatChanged will always be
called when the renderer is re-enabled, since the codec may be kept
and its output format may not change. Hence we need to avoid resetting
state in onDisabled that we need when the renderer is enabled again.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219821519
Currently, MediaCodecRenderer's render loop does not have any time limit. We
always try to drain and feed as much buffers as possible. This may lead to a
pattern of feeding phase takes too much time from previous loop, which makes
the next draining phase drops all buffers, making these buffers available for
feeding all at once, and the pattern keeps repeating.
This CL adds an experimental parameter for setting a time limit. If the time
limit is exceeded, the feeding process stops even if more input could be fed.
The default behavior is unchanged
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219820386
This makes extractor selection a bit more efficient for some CMAF files.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219795105
This prevents leaving an inconsistent state after a EOF exception.
Issue:#5039
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219785275
Before this change, the player state would be STATE_ENDED then
STATE_BUFFERING (when the postroll ad was marked as played) then
STATE_ENDED again.
Queueing a final content media period with start point equal to
the content duration after a postroll ensures that the player
state doesn't change to STATE_ENDED transiently.
Switch from using C.TIME_END_OF_SOURCE to C.TIME_UNSET for media
periods that should not have an end point and are not followed
by an ad.
Content media periods before postrolls have end position
C.TIME_END_OF_SOURCE. If the postroll ad loads, its content
position is set to the content duration, which should be known
at the point of loading the postroll, then a final 'empty'
content media period with start position equal to its duration
is queued. If the postroll fails to load, this empty content
media period is queued up directly after the preceding content
media period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219443683
- Handling EVENT_PROVISION_REQUIRED is unnecessary because we handle
it via NotProvisionedException, which was thrown on all API levels.
- Handling EVENT_KEY_EXPIRED during playback is unnecessary. All it
does is cause an error to be thrown, but an error will be thrown
anyway out of the MediaCodec when it tries to use the expired keys.
It's currently a race condition where the error gets thrown from,
where-as having it always be thrown from one place is preferable.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219172021
This paves the way to cleanly fix the first two issues
listed in [] onDisabled will null inputFormat,
but nulling of codecFormat will remain tied to the codec
being released.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219125458
ExoCastMessage contains all player management messages that the sender app can
send to the receiver app. ExoCastMessages can be serialized as JSON strings.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218846977
- Only use bitrate when comparing two tracks if their bitrates are
actually different.
- For audio, prefer to use bitrate over selection flags.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218660886
- Improve variable naming
- In the edge case that bytes are transferred in a sample that
has 0 elapsed time, carry the bytes forward into the next
sample. If we don't do this then the estimate will be calculated
as though those bytes were never transferred. In practice I
suspect this very rarely occurs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218551208
