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
If EventDispatcher.removeListener is called to remove a listener,
and if the call is made from the same thread that said listener
handles events on, then it should be guaranteed that the listener
will not be subsequently invoked on that thread.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218331427
In ConcatenatingMediaSource, the source may be removed before it started
preparing (this may happen if lazyPreparation=true). In this case, we
shouldn't call releaseSource as the preparation didn't start.
Issue:#4986
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218141658
There are multiple subtle issues with the current implementation:
1. setOperatingRate can cause a codec initialization even if the
renderer is disabled. This is not supposed to happen.
2. If the codec is released whilst the renderer is disabled, the
renderer can instantiate a new codec using the old format when
it's enabled again, only to immediately have to reconfigure or
release it if the actual format to be played is different.
3. Codec reuse does not take into account renderer configuration.
The specific case where this is problematic is if the video
renderer is re-enabled with a different tunneling session id.
The reused codec is then not configured correctly.
Also moved availableCodecInfos reset into releaseCodec for sanity.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217924592
This is a no-op change as the respective values are not used so far but
the change makes the current state cleaner and is less error-prone.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217892421
- Added ability to override the DefaultBandwidthMeter network type.
- These methods currently only work properly if called before the
meter is used, but the plan is for them to be handled in the same
way as internally detected network changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217887019
This method only ensured backward compatibility while the new version was not
public yet. Now ExoPlayer 2.9.0. is public, this workaround can be removed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217881691
