ExoPlayer.setRepeatMode should be preferred. Deprecate
the constructor and update the relevant documentation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157829207
This is necessary to make sure that the correct thing happens
where MediaCodecInfo.adaptive is queried directly (for example,
MediaCodecVideoRenderer uses the field to determine how to size
input buffers). Also disable adaptive on Nexus 10.
Issue: #2806
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157583473
We do this everywhere for index based seeking already.
Issue: #2876
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157568788
Use AUDIO_UNKNOWN instead. This is in line with our handling
of video tracks with VIDEO_UNKNOWN.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157209428
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
*** Reason for rollback ***
This change may silently introduce bugs where both parameters are acceptable in both places. It's decided that the gain isn't worth the risk.
*** Original change description ***
Make the error messages the first parameter in Assertions methods to match JUnit methods
Reverse parameter order creates a slight confusion.
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156844728
Expose the stream offset to BaseRenderer subclasses.
Issue: #2267
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156837514
([]
This change has been automatically generated by an Error Prone check that
detects incorrect argument ordering on calls to assertEquals-style methods. See
[]
Cleanup change automatically generated by javacflume/refactory
Refactoring: third_party/java_src/error_prone/project/core/src/main/java/com/google/errorprone/bugpatterns/argumentselectiondefects:AssertEqualsArgumentOrderChecker_refactoring
Tested:
TAP --sample for global presubmit queue
[]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156739144
(Related to GitHub Issue #2577)
Added test to ExoPlayerTest which changes the repeat mode during playback.
Test verifies that ExoPlayer shows the periods in the intended order.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156168166
- Call onDisabled last. onDisabled really shouldn't be doing
anything with the stream, so pretty sure this is fine (and
guarantees the stream is cleared properly even if onDisabled
throws a RTE).
- Remove super.onDisabled calls from Text/Metadata renderers.
This is just for consistency; we don't make such calls in
other direct descendants of BaseRenderer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156130640
If a timeline update removed periods at the end of the timeline which
had been buffered, handleSourceInfoRefreshed would call
getNextPeriodIndex and get back -1 for the last period holder in the
new timeline. Then isLastPeriod(-1) could throw.
Fix this behavior so that the remainder of the timeline is discarded.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156061016
Checking the expected next/previous window indices and if the correct window
or period gets returned.
TimelineTest defines mock classes and verification methods used by the specific
implementation tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155727385
When readingPeriodHolder and playingPeriodHolder are both null, a
NullPointerException is thrown when trying to reassign readingPeriodHolder.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155635846
(Relating to GitHub issue #2577)
Changing the repeat mode during playback may require to discard or rebuffer
certain periods because the requested order of playback changed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155600910
(Relating to GitHub Issue #2577)
The Timeline base class provides the default implementation.
Timeline wrappers (e.g. ClippingTimeline, ConcatatedTimeline) forward all
requests to the respective inner timelines. Some like ConcatenatedTimeline add
their own additional logic to bridge between the child timelines.
In addition, ConcatenatedTimeline and LoopingTimeline now have a common
abstract base class as they share most of their code.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155509269
Even though this is not strictly spec compliant, this will make exoplayer
behave like it used to before multiple program support. Developers
who want to take advantage of the multiple program support are probably
less than the ones who only want their stream to "just work". This is
particularly useful for streams obtained after a filtering component,
like a tv tuner.
Issue:#2757
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155486122
This will allow supporting more encryption schemes. Including some
that require more encryption data, like the encryption pattern.
Issue:#1661
Issue:#1989
Issue:#2089
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155481889
This is most commonly caused by malformed media, where
the media indicates that something we need to make an
allocation for is *really huge*. Failing playback is
appropriate for this case; killing the process is not.
Issue: #2780
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155408062
Added repeat mode toggle buttons to UI. Current mode gets forwarded to
Exoplayer instance, but without playback behaviour changes yet.
Translations for button descriptions are also missing - this will be another CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155386549
The default byte order for ByteBuffers is big endian, but platform decoder
output buffers use native byte order. AudioProcessors handle native byte order
input/output.
When using a software audio decoding extension the Sonic audio processor would
receive big endian input but was outputting to a native byte order buffer,
which could be little endian. This mismatch caused audio output to be
distorted.
After this change both platform decoder and extension decoder output buffers
should be in native byte order.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155320973
If the codec isn't adaptive, there's no need to accommodate
the width/height/input-size of streams that don't have the
same resolution as the current stream. This is because we'll
always need to instantiate a new codec anyway.
Issue: #2607
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155194458
(Relating to GitHub Issue #2577)
All getter, setter and callbacks have been added and value of repeatMode is
passed to getNextXXXIndex methods.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155071985
A DummySurface is useful with MediaCodec on API levels 23+.
Rather than having to release a MediaCodec instance when the
app no longer has a real surface to output to, it's possible
to retain the MediaCodec, using MediaCodec.setOutputSurface
to target a DummySurface instance instead. When the app has
a real surface to output to again, it can call swap this
surface back in instantaneously. Without DummySurface a new
MediaCodec has to be instantiated at this point, and decoding
can only start from a key-frame in the media.
A future change may hook this up internally in MediaCodecRenderer
for supported use cases, although this looks a little awkward. If
this approach isn't viable, we can require applications wanting
this to set a DummySurface themselves. This isn't easy to do with
the way SimpleExoPlayerView.setPlayer works at the moment, however,
so some changes will be needed either way.
Issue: #677
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154931778
Looper.myLooper(), the default looper, may be null in background threads. This adds a fallback to use the main app looper.
This will allow ExoPlayer instances to be built in background threads in Photos.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154845446
Using the new getNextWindowIndex method of Timeline, LoopingMediaSource now
uses a InfinitelyLoopingTimeline which does not unroll the windows to
157 million iterations but just starts from the beginning. If an explicit
number of iterations is given, we still unroll.
This change also allows multi-window timebars to show infinitely looping
playlists correctly.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154817554
(Preparation for Repeat Toggle Function - GitHub Issue #2577)
In addition, Timeline now also got a getPreviousWindowIndex and a
getNextPeriodIndex method with default implementations.
Changed ExoPlayerImplInternal and PlaybackControlView to use these
methods at all occurances of period and window index operations.
Note: Does not include repeat mode yet and no timelines are actually
using it so far. Please wait for the next CLs for this.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154520664
To inject custom renderers into SimpleExoPlayer, developers
currently need to extend SimpleExoPlayer and override the
renderer building methods. This is in contrast to the rest
of the library, where we use proper injection. This change
restores consistency. I think it's fine to make
SimpleExoPlayer final again, but if we find people extending
it for non-renderer purposes, we can revert that part of the
change.
ExoPlayerFactory now has analogous methods for the simple
and non-simple cases, which is a nice outcome.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154295726
Fixes the following issues:
1. When a surface is set, it's expected that the renderer will
notify video size + when a frame is rendered to it. This is true
even if the surface isn't changing. Right now this is achieved
by setting renderedFirstFrame to false, but this is problematic
in the case that the surface isn't changing because (a) it will
force rendering of a subsequent frame to the output even when
paused, which is incorrect, and (b) isReady will return false
until this occurs.
2. When the surface really is changing, isReady can return false
until the first frame has been rendered into the new surface, which
will break seamless surface switching. This change allows isReady
to return true up to allowedJoiningTimeMs for this case.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154171111
* colorSpace, colorRange and colorTransfer are relevant to all videos.
* The rest of the fields are relevant only to HDR videos.
* Tested on a prototype device that decodes VP9 profile 2, 10 bit.
* The Webm spec spells color as 'colour' so the webm id reference use the same spelling.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154098189
Prior to this change, the only way to switch SimpleExoPlayerView
was to do:
oldView.setPlayer(null);
newView.setPlayer(player);
This would cause the video renderer to have to transition through
oldSurface->noSurface->newSurface, which is inefficient (noSurface
requires platform decoders to be fully released).
After this change we support:
newView.setPlayer(player);
oldView.setPlayer(null);
This results in direct oldSurface->newSurface transitions, which are
seamless on Android M and above. The change also adds some robustness
against developers ending up with strange behavior as a result of
clearing the player from a view in a different ordering than we expect
w.r.t. registering of other listeners.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154044976
This class is unnecessary; you can simply pass a thread
priority to HandlerThread's own constructor. It's also
broken, since HandlerThread.run() immediately overrides
the priority being set!
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=153461225
If AudioTrack.setPlaybackParameters was called before initialization (for
example, when an audio renderer is enabled) the parameters would actually be
dropped, because configure calls reset, which didn't apply draining playback
parameters if the track was not initialized. It would then overwrite the
draining parameters with the current parameters.
Set the playback parameters directly (without draining) for uninitialized tracks
so that the call to setPlaybackParameters in configure is a no-op.
Also, reset the stored channel count and sample rate when the audio processor
is released so that configure returns true when it is next used, which makes
sure that it gets flushed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=153078759
The track initialization data of Tx3g includes default style values for
font styles, colour, and font family. Additionally the decoder now supports
vertical subtitle placements other than the Tx3g default of 85% video height.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152930057
The idea of using reflection was so that a developer could
delete a package they didn't want and have everything else
still compile. However, a developer doing this is likely
building from source, in which case editing the factories
too is pretty trivial.
Removing the reflection makes specifying extractor flags
via the default factory easy, and removes the need for
special proguard config.
Issue: #2657
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152810423
Extended Tx3gDecoder to read additional information after subtitle text.
Currently parses font face, font size, and foreground colour.
Font identifier and other information provided in subtitle sample description
not yet supported.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152793774
When no video tracks or renderers are present, attempt audio adaptation.
Issue:#1975
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152708422
I've also removed unnecessary "empty" cases, since to add them
everywhere would bloat the code quite a lot. Note that
new String(new byte[0], 0, 0, encoding) is valid and will produce
and empty string.
Issue: #2663
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152697288
This allows propagating format changes to the track output.
Issue:#2552
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152672983
ExoPlayerImpl.prepare() replaces the timeline with an empty timeline. After this
happens, MSG_SOURCE_INFO_REFRESHED could be handled on the main thread and
could relate to the old source, so the player could expose a stale timeline.
Count pending prepares in ExoPlayerImpl so that source info refreshes can be
suppressed until preparation actually completes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152496255
- Removed the PES_STRIPPED flag. It's unnecessary. We can strip
PES in the TS extractor instead.
- Made nearly all of the object classes in DvbParser immutable.
Else it's non-obvious that none of this state can be mutated.
- Made a a lot of the methods in DvbParser static for the same
reason.
- Removed unnecessary null checks, code that was never executed,
unused fields etc.
- Add proper flushing of DvbParser, to prevent corrupt output
following a seek.
Only enable multi-window mode when the duration of every period in the timeline
is known. Also, remove the warning logged when there are too many windows as it
doesn't add much.
The player's current period index was not masked while there were
unacknowledged seeks. This led to the displayed position jumping, between when
seekTo was called (after which the position would be masked but not the period
index) and the seek being acknowledged (at which point the time bar's position
would jump back to the seek position, due to the period index being resolved).
Mask the period index, like the window index, to fix this behavior.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=152116040
Start draining the audio processors when the playback parameters change,
and when draining completes use the written frame count and next input
buffer presentation timestamp as an offset for applying the new playback
speed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151800074
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
This is the boring part of a larger change that fixes
how video renderers behave when surfaces are attached and
detached whilst they're enabled or started.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151563031
'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
- Validate frames for majorVersion 2 and 3 as well as 4
- Don't throw if top bit of frameSize is non-zero.
Issue: #2604
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151348836
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
Also move it closer to the ExoPlayer code style.
Note: This change is intended to be purely cosmetic.
Issue: #26
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151307575
Also add an isAd flag to Timeline.Period so that periods can be declared as
containing ads. The times of these periods are indicated using ad markers in
the new TimeBar.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151116208
Add methods to ExoPlayer for setting/getting the playback speed, using
SonicAudioProcessor.
Remove PlaybackParams support, as the AudioTrack timestamp does not work
reliably on Marshmallow. The platform also uses Sonic and performance
should be comparable between the Java and native versions on recent Android
runtimes.
In a later change, SonicAudioProcessor will be made public so it can
be used in conjunction with other processors.
Issue: #26
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151027121
The way it was before worked, but it's not really documented
that DrmSession methods implemented by DefaultDrmSessionManager
can be called after the session has been released, and it feels
wrong to do this.
At some point we should probably consider moving the DrmSession
part of DefaultDrmSessionManager into an inner class, to force
usage in the "normal" way.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=151003855
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
Also renamed releaseResources->release to be consistent with the
rest of the library, and added some synchronization to ensure
correct usage.
Issue: #2139
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150753414
1. Move entire library from v2/library/ to v2/library/core
2. Add v2/library/all that depends on v2/library/core
Issue: #2139
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=150455693
