- Fix issue in ExoPlayerImpl where the timeline was null'd
but onTimelineChanged was not fired.
- Add the ability to not reset the timeline. This is useful
for retries where you know the timeline will be the same
as it was previously.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135797577
This prevents a large amount of memory from being held
in the case that a player instance is released, but the
application is holding dangling references to the player
that are preventing it from being garbage collected.
Issue: #1855
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134992945
- This change fixes seeking before the prepare (or more
accurately, before the timeline is set). The fix a minimal
one to fix the behavior. It's inefficient compared to
posting the pending seek onto the playback thread, which
will be the long term solution.
- As of this change, I think we can call V2 "done". There are
some loose ends to tie up, but the API is effectively
finalized and the implementation is in a state where you
can take it, use it and expect it to work.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132468107
There's still some internal to clean up to do, and in particular
it remains a TODO to be able to handle seek calls before the
timeline is set (for this CL, such calls are dropped). This change
does however finalize the API.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131171318
Window is potentially confusing with Android's Window class.
Once Window is renamed, it makes sense to rename Timeline too.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130938392
- Use a single constant for unset/unknown times across
all time bases. Note also that this moves away from
use of -1 for unset/unknown times in ms, which was a
bad choice (it might conflict with real times, such
as a time representing being just behind the start
of a live window).
- Add a few other unset constants, and use them.
- Fix some hardcoding of -1 where existing constants
should have been used.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130775594
- Remove getNewPlayingPeriodIndex from MediaSource
- Remove all absolute references to period indices from
Window. Their existence prevents ConcatenatingMediaSource
from being able to efficiently handle children with
large numbers of entries (e.g. a cursor backed source),
since it would copy all windows into its merged timeline.
- Fix ExoPlayerImplInternal to attempt a restart in the
case that the loading (but not yet prepared) period is
removed, in absence of a playing period.
- Implement logic for finding the "next" period in the old
timeline when attempting a retry.
Removing some of the nasty US<->MS conversions left as a
virtual TODO.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130659973
- This change marks the methods that will be removed, and
renames the Window methods to remove "Window" from their
names.
- The Window methods need to be made to work (rather than
throw exceptions) when the timeline isn't set. Once that
gets done in a subsequent CL, the deprecated methods will
be removed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130612979
- This change also enables seeking in live windows in the
ExoPlayer demo app.
- The added playlist doesn't transition properly by itself,
but for manual transitions it works correctly, and
demonstrates seeking into a default position.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130515880
This was always a bit of a hack; for Play Movies. It may well
no longer be necessary, and if not I'd like to think of a nicer
or more general way of doing it. We can always bring it back
if needed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130373433
- This avoids the need to have to use the timeline to
calculate a window duration, which can be awkward.
- Window now represents a window of availability with
an isSeekable flag, rather than a window of
seekability.
- Promoted Timeline and Window to top package; they're
pretty important :).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130278509
It's no longer safe to convert END_OF_SOURCE -> duration on
the main therad, since the Timeline from which the duration
is obtained is posted to the main thread, where-as the
buffered position is passed by updating a volatile. Hence
an update to the latter might become visible to the main
thread before the corresponding Timeline.
This change moves the conversion to the playback thread.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130265893
When seeking to the default position in a period, the containing source may
actually return a position in another period. Multi-period live sources can do
this to seek the player to the live edge.
ExoPlayerImplInternal uses the same functionality when the playback position
reaches the end of a period to determine what period/position to play next.
This means that when playback transitions to a multi-period live source from
some other source (playing a concatenation of those two sources), the player
will play the live edge rather than the beginning of the earliest period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=128984355
- Invoked --> Called
- Gets --> Returns
- "True if X. False otherwise." --> "Whether X."
- Removed some @returns where the Javadoc is in "Returns X" form
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=128678638
This change restores ExoPlayer to its previous behaviour.
I think we'll want a "resetPosition" boolean parameter on
setMediaSource at some point, but no need to add it right
now. Note that this would not always reset to the start
of the source. For a live playback it will reset to the
desired position (normally somewhere slightly behind the
live edge).
Issue: #1667
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127549700
It doesn't look like TrackSelectionPolicy is going to be
useful other than with DefaultTrackSelector, and it's kinda
confusing dealing with both "selector" and "policy"
terminology. This change does the following:
DefaultTrackSelector -> selector.MappingTrackSelector
DefaultTrackSelectionPolicy -> selector.DefaultTrackSelector
TrackSelectionPolicy -> [deleted]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127196326
- The package is renamed to avoid conflicts with v1, should any
app wish to include both v1 and v2 for a period of time. This is
similar to the approach used by some other open source projects
(e.g. okhttp).
- Copyright year is updated everywhere for completeness.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=126895326
2016-07-08 12:12:09 +01:00
Renamed from library/src/main/java/com/google/android/exoplayer/ExoPlayerImpl.java (Browse further)
