This removes the need for separate String/Parcelable filter paths in
the demo app. Hopefully this is a temporary measure as we work
toward using track groups + consistent keys for all media types.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=194065499
These don't seem to be needed anymore. All tests run without them in gradle
and Blaze.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191867518
This field (formerly "id") is almost impossible to use so far. Having setters
in the factories allows to specify custom tags for all media sources.
Also added a ExoPlayer.getCurrentTag() method to retrieve the tag of the
currently playing media source in a convenient way.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191738754
Erroneous condition:
===================
If the track selection contains a subset of the available variants in the
master playlist, but only the selected variants return 404, the playlist
tracker will never propagate the error.
Fix:
====
The Chunk source will propagate the playlist load error if no more
alternative playlists are available (because all are already blacklisted).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190624484
Currently, MediaPeriod states that continueLoading may be called
during preparation. Some implementations would throw an error if
this happened.
Also make MediaPeriod documentation clearer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190596870
This adds callbacks for creating, releasing, and starting to read from media
periods.
Such events allow listeners to keep a list of active media periods. This is
useful to determine when no further events for a certain media period are
expected. It also allows listeners to associate renderer events unambigiously
with a reading media period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190462717
This allows to distinguish between media source events of multi-window and
multi-period media sources. In this change, only media sources currently reporting
events are changed. Proper support in composite sources will be added in a later
change.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188847366
This is achieved by moving the listener registration and the creation of the
event dispatcher into BaseMediaSource.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=188461932
Before this change, HlsMediaSource timelines had a period starting at the epoch.
For VOD streams the window position in the period was the program date time.
This change makes period and initial window positions match. For live streams
the window position advances as segments are removed, so its position in the
period is the difference between the initial program date time and the program
date time of the latest playlist.
This also makes it possible to insert ads in VOD HLS content with program date
time, as the period and window are now aligned.
Issue: #3865
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187590948
- Change 'compile' configuration (deprecared) to using 'implementation'
and 'api' configurations instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187311778
This is achieved by adding a BaseMediaSource which keeps a reference count of the
number of times the source has been prepared and forwards to the actual implementations
only once, such that only minimal changes are needed for each media source.
Issue:#3498
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=187186691
Releasing the player released the internal playback thread once renderers were
released. Releasing a MediaPeriod queued a Loader.ReleaseTask on the loading
thread which would post back to the playback thread. If the playback thread had
been quit by the time this happened, the release task wouldn't be run.
Release on the loading thread instead of the playback thread. This avoids
needing to block releasing the player until the loading threads have ended, and
ensures that release tasks will run eventually. As part of this change,
ExtractorMediaPeriod's call to Extractor.release will now run on the loading
thread (which means that all Extractor methods are called on that thread) and
other cleanup in ReleaseCallback will run on the loading thread instead of the
playback thread.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=185651320
These parsers can be used to get a manifest which includes only the
representations identified by the given keys.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182932874
This achieves two things:
1. All our tests use the same type of assertions.
2. The tests currently run as instrumentation test can be moved to
Robolectric without changing the assertions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182910542
This solves the problem of having dense tracks' ids change.
For example, if the available variants offer both HEVC and AVC video
tracks, all video samples will map to the same sample queue even if
IDs don't match.
Issue:#3653
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182070486
This lets apps fail-fast when they try to reuse media source instances.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180934445
- Convert the Builder into a Factory
- Have it use MediaSourceEventListener
- Also made some misc related fixes to other sources
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=178906521
If allowed, the media period will try to finish preparation without downloading
chunks (similar to what DashMediaPeriod does). To create track groups,
HlsMediaPeriod will try to obtain as much information as possible from the
master playlist. If any vital information is missing for specific urls,
traditional preparation will take place instead.
This version does not support tracks with DrmInitData info. This affects tracks
with CDM DRM (e.g: Widevine, Clearkey, etc). AES_128 encryption is not affected.
This information needs to be obtained from media playlists, and this version
only takes the master playlist into account for preparation.
Issue:#3149
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=178098759
In some occasions, we may want to discard a part of the buffered media to
improve playback quality. This CL adds this functionality by allowing the
loading media period to re-evaluate its buffer periodically (every 2s) and discard
chunks as it needs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177958910
In order to facilitate enabling a compile-time error check, we are suppressing these existing instances. Once the compile-time error is enabled, we will file bugs to clean up any unfixed instances in [].
Note that this CL should result in no effective changes to the code, but the code as currently-written might contain a real bug. If you'd prefer to fix the bug now, please either reply with edits, or accept this CL then follow up with a change that fixes the underlying issue.
Tested:
tap_presubmit: [] Some tests failed; test failures are believed to be unrelated to this CL
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177836122
We've found that in our production environment, the AAC stream's timestamp exceeds the 33bit limit from time to time, when it happens, `peekId3PrivTimestamp` returns a value that is greater than `TimestampAdjuster.MAX_PTS_PLUS_ONE`, which causes a overflow in `TimestampAdjuster.adjustTsTimestamp` (overflow inside `ptsToUs`) after playing for a while . When the overflow happens, the start time of the stream becomes negative and the playback simply stucks at buffering forever.
I fully understand that the 33bit is a spec requirement, thus I asked our stream provider to correct this mistake. But in the mean time, I'd also like ExoPlayer to handle this situation more error tolerance, as in other platforms (iOS, browsers) we see more tolerance behavior.
Also prevent skip when there's a pending reset, and add a
TODO to split/fix chunk discard and downstream format change
reporting.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176760955
Currently for a DASH ChunkSource that consists of multiple sub-streams, we
always use a CompositeSequenceableLoader, which only allows the furthest behind
loader or any loader that are behind current playback position to continue
loading.
This changes allow clients to have more flexibility when deciding the loading
strategy:
- They can construct a different kind of composite SequenceableLoader from
the sub-loaders, and use it by injecting a different CompositeSequeableLoaderFactory accordingly.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176363870
Add Builder pattern to HlsMediaSource and mark existing constructors as
deprecated.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175803853
This is a step toward retaining a back-buffer in a way that
works for all MediaSource implementations. It's not possible
to adjust the discardBuffer calls in ExoPlayerImplInternal
to discard up to (position - backBufferDurationUs). Next steps
are to:
1. Find an appropriate place to specify the back buffer value,
to be passed to the discardBuffer calls. I guess the
LoadControl is the appropriate place to define such values.
2. Enhance discardBuffer to support a toKeyframe argument to
pass through to discardTo.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175565363
This CL does not aim to introduce any functionality changes.
Issue:#3149
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174864875
This is the first CL in a series to add chunkless preparation support.
Also did a bit a tidying up in HlsSampleStreamWrappen and
HlsMasterPlaylistParserTest.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174461737
This also allows exposing multiple CC channels to any fMP4 extractor client.
Issue:#1661
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174458725
- When transitioning to a new period, the value of bufferedDurationUs
passed to TrackSelection.updateSelectedTrack was incorrectly set to
0. It should have been set to correctly reflect buffered media in
previous periods still being played out.
- This change fixes the issue described above, and also propagates the
playback position through to this method. The position of the next
load within the period can be calculated by adding the position and
bufferedDurationUs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172736101
Also create helper method in HlsMasterPlaylist to allow the copying of
the playlist to another, but with the variants reordered based on a
passed comparator. Also added an implementation of HlsPlaylistParser
which will reorder the variants returned.
Follow-up on the update to ABR logic in AdaptiveTrackSelection for live
streaming case:
- Do not reset liveEdgeTimeUs when user seek to a different position.
- For HlsChunkSource, for non-independent segments, currently the
bufferedDuration calculate will subtract previousChunk's duration. So to make
it work with live-streaming ABR logic, we subtract timeToLiveEdgeUs a similar
amount to compensate for that operation.
- Minor update to DefaultSSChunkSource, only perform TrackSelection when needed
(after checking necessary conditions).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169531275
This includes both cbcs and cenc. Will only work for streams that require a single
pssh.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169382884
In live streaming, if the playback position is very close to live edge,
the buffered duration will never reach minDurationForQualityIncreaseMs,
which prevents switching from ever happening. So we will provide the
durationToLiveEdgeUs to AdaptiveTrackSelection in live streaming case,
so it can handle this edge case.
GitHub: #3017
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168535969
We currently switch without downloading overlapping segments, but
we do not actually switch more aggressively. This change fixes
this. Note there's an implicit assumption made that if one media
playlist declares independent segments, the others will too. This
is almost certainly true in practice, and if it's not the penalty
isn't too bad (the player may try and switch to a higher quality
variant one segment's worth of buffer too soon).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167120992
This parameter is used by methods such as getNextWindowIndex
and getPreviousWindowIndex to determine the playback order.
Additionally, there are method to query the first and last
window index given the shuffle mode.
None of the timeline implementations nor the ExoPlayer
implementation supports shuffling so far.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166170229
Also add sample streams that use METHOD=SAMPLE-AES. Note that some of
the streams provide alternative EXT-X-KEY's. Support for alternative
decryption methods will be added in a later CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166048858
Also instantiate the resulting list with a predicted size to minimize
list resizing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163332285
Creates a copy of this playlist which includes only the variants identified by the given variantUrls.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163212562
When resetting a SampleQueue, by default the upstream format
is not cleared. This is necessary for progressive playbacks,
since (a) the formats never change, and (b) the extractors
only output them once. So when a seek occurs, it's necessary
to clear all sample data from the queue, but retain the current
upstream format.
Uniquely for HLS, the media in a SampleQueue that we may read
from can be in a format not supported by the consuming renderers.
We clear all the sample data from the queue in this case, but
not the upstream format. Since we have an optimization that
allows the upstream format to be read in advance of another
sample being written into the queue, this can result in an
unsupported format being read by a consuming renderer. This
change ensures the upstream format is correctly cleared in the
problematic case.
Issue: #3079
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162360267
All implementations of SequenceableLoader already implement this method.
Moreover, all composite media periods contained an exact copy of an
implementation that now moved to CompositeSequencableLoader.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162349083
Also move to using an array to hold the SampleQueues,
as we've moved to doing in ExtractorMediaPeriod.
Issue: #551
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161972990
This CL aims that the player fails upon:
- Playlist that don't change in a suspiciously long time,
which might mean there are server side issues.
- Playlist with a media sequence lower that its last snapshot
and no overlapping segments.
This two error conditions are propagated through the renderer,
but not through MediaSource#maybeThrowSourceInfoRefreshError.
Issue:#2872
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160899995
This prevents ExoPlayer from thinking there are many more video tracks
than there actually are. And will prevent downloading multiple times
the same rendition once offline support for HLS is added.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160285777
With this change, it becomes possible to depend on ExoPlayer
locally in settings.gradle by doing:
gradle.ext.exoplayerRoot = 'path/to/exoplayer/root'
apply from: new File(gradle.ext.exoplayerRoot, 'core_settings.gradle')
You can optionally add a prefix onto ExoPlayer's module names
by adding:
gradle.ext.exoplayerModulePrefix = 'prefix'
Issue: #2851
Issue: #2974
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160277967
It's currently difficult to use ExoPlayer modules in other gradle
projects because they rely on constants and dependencies defined
in our own top level gradle file. This change moves the constants
into a separate file referenced directly from each module. It also
removes the need for the top level gradle file to declare a
dependency on com.novoda:bintray-release. This is now only needed
if "exoplayerPublishEnabled = true" is specified.
Issue: #2851
Issue: #2974
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160272072
This will allow MediaSources to provide MediaPeriods that correspond to ad
breaks in a timeline period rather than content for a timeline period, in a
future change.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160267841
Made the method copy all of the fields of DataSpec in to the new instance. Also converted
it to an instance method of DataSpec for ease of usage, discovery and maintenance.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159670314
Currently, media is discarded from DefaultTrackOutput
and SampleMetadataQueue as soon as it's been read. In
upcoming changes we'll decouple discard and read. This
will make it possible to retain already-read media in
these buffer classes, and allow the read position to
be moved backward as far as media is retained. This is
important for fixing an edge case around 608/EMSG
tracks, and could also underpin future features like
allowing retaining of X-seconds past media in the
buffer.
This change renames some variables and methods to
prepare for the upcoming changes. read/write indices
are renamed to start/end. The upcoming changes will
add a read index that's between the two. isEmpty is
inverted and renamed to hasNextSample, since it will
be possible to not have a next sample (because the
read index == end index) but for the buffer to not
be empty (because start index < read index).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158409630
1. Remove tools:replace in manifest files. This attribute is only needed to establish priority when two manifests are merged and have the same attribute with different values.
As this is not happening here, the attributes can be removed.
2. Some BUILD files also define a deprecated manifest merge strategy different from the android default merge strategy. For consistency these are set to "android'.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158075128
Also prevent BANDWIDTH's regex from matching the AVERAGE-BANDWIDTH attribute.
Issue:#2863
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157219453
"other" includes tags for which there is no existing behavior defined.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157217270
It is worth mentioning that the tag can be in the master playlist as well, which
means that it applies to all media playlists. There are a few tags with this
characteristic. This will be addressed in a later CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157210505
This fixes transitioning into the ended state if we see
endOfStream from the chunk source whilst in the pending
reset state. Prior to this fix we'd still be pending a
reset, and so readData would never allow EOS to be read
by the consuming renderer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157101755
This change also ensures that format changes are read whilst the
renderer is enabled but without a codec. This is necessary to
ensure the drm session is updated (or replaced).
Updating the format is also needed so that the up-to-date format is
used in the case that the codec is initialized later due to the
surface being set. Previously, if an ABR change occurred between
the format being read and the surface being attached, we would
instantiate the codec and then immediately have to reconfigure it
when as a result of reading the up-to-date format. For a non-adaptive
codec this resulted in the codec being immediately released and
instantiated again!
Issue: #2582
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151608096
'library-core' is still affected by https://code.google.com/p/android/issues/detail?id=226070
Code coverage report can be generated for the rest of the modules by:
./gradlew :[module name]:createDebugCoverageReport
Report is generated under:
[module folder]/buildout/reports/coverage/debug
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151448536
If the super method has the annotation on an argument, then
the overriding method should have it too.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151440313
The only case where we should pass false is if we want to know
whether the passed time is within the buffered media. This is
relevant within seekTo implementations only.
This is related to (but does not fix) issue #2582
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151315676
Notes:
- Now only generating a single module Javadoc task for the
release variant.
- Combined Javadoc now includes extensions. VP9 is excluded
for now since it's failing for an unknown reason.
Issue: #2139
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150865589
Notes:
- The VP9 one is failing claiming that the util package
doesn't exist and that LibraryLoader cannot be found.
Unsure why, since it appears to be setup exactly like
other extensions (e.g. Opus) that does work.
- @link across modules will not work when generating
Javadoc for a single module. This is WAI. I subsequent
change will add an aggregated Javadoc generator that
will generate Javadoc for all modules together and
apply cross module @link correctly.
Issue: #2139
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150864273
