This can be used by the app for showing arbitrary UI on top of the player (for
example, UI elements associated with an ad).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138610733
These variables are never read, since the underlying control
view reads them directly from the attrs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138528246
This fixes VOD->Live transitions, with the caveat that
the Live portion still ends up further behind the live
edge than intended. This will be fixed in a following
change.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138407066
This change fixes the race condition where the internal
timeline is different to the externally visible timeline
when a seek is performed. We now resolve the seek position
using the externally visible timeline, then adjust the
period index as required for the internal timeline. If the
period is missing we follow similar logic for the existing
case where the playing period is removed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138402076
This CL adds a SpliceInfoDecoder for the most common SCTE35 commands for splcing.
So far, it only includes TransportStreams, but porting it to HLS and DASH should be
fairly easy.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138389807
This is the first step towards allowing discontinuities in the
playlist tracking. Also changed durationSecs for durationUs in
MediaPlaylist.Segment.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138207732
handlePeriodPrepared
->setPlayingPeriodHolder
->enableRenderers
passes rendererPositionUs to renderer.enable(), but
this value is not set correctly.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138176114
A VOD-style period in a dynamic manifest would result in a NullPointerException.
Also fix another issue in which an unrecognized mime type would also result in
NullPointerException.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138075137
In order to expose the live window, it is necessary (unlike before) to refresh
the live playlists being played periodically so as to know where the user can
seek to. For this, the HlsPlaylistTracker is added, which is basically a map
from HlsUrl's to playlist. One of the playlists involved in the playback will
be chosen to define the live window. The playlist tracker it periodically.
The rest of the playilst will be loaded lazily. N.B: This means that for VOD,
playlists are not refreshed at all. There are three important features missing
in this CL(that will be added in later CLs):
* Blacklisting HlsUrls that point to resources that return 4xx response codes.
As per [Internal: b/18948961].
* Allow loaded chunks to feed timestamps back to the tracker, to fix any
drifting in live playlists.
* Dinamically choose the HlsUrl that points to the playlist that defines the
live window.
Other features:
--------------
The tracker can also be used for keeping track of discontinuities. In the case
of single variant playlists, this is particularly useful. Might also work if
there is a that the live playlists are aligned (but this is more like working
around the issue, than actually solving it). For this, see [Internal: b/32166568]
and [Internal: b/28985320].
Issue:#87
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=138054302
- Use A/V tracks only for buffering position when available
in ExtractorMediaPeriod.
- Fix layering of exo_simple_player_view so that subtitles
are above album art. The test stream provided has both.
- Make album art in SimpleExoPlayer view respect the resize
mode, like we do for video.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137698473
TrackSelector no longer has a listener. Instead, tracks
change events are reported through ExoPlayer.EventListener.
Applications interested in retrieving the selection info
should retrieve it directly from the TrackSelector by
calling an exposed getter.
Pretty sure the ref'd issue is fixed as a side effect of
this change.
Issue: #1942
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137183073
Unlike with PesReaders, sections don't have a standard way
of providing timestmaps or even generating tracks. We need
to pass this information so that readers decide what to do
with it.
Issue:#726
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137162494
This allows the user to create section readers(usually) for reserved pids,
like SDT, EIT, CAT, etc.
Issue:#726
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=137150853
SectionPayloadReaders are provided to a SectionReader to
get whole sections(crc checked). This allows the injection
of custom section readers. E.G: SCTE35 messages.
Issue:#726
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136816612
In this CL:
* PesReader moves out of TsExtractor and becomes public.
* ElementaryStreamReaderFactory becomes TsPayloadReaderFactory and is
moved to TsPayloadReader.
* The TsPayloadReaderFactory is in charge of wrapping any
ElementaryStreamReaders with a PesReader.
Incoming:
* Extract SectionReader supperclass (analog to PesReader, but for
sections) from Pat and Pmt readers.
* Add a ScteReader, wrapped by a section reader, and include it in
the DefaultTsPayloadReaderFactory.
Issue:#726
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136707706
pesPayloadReader can be null here because DefaultStreamReader.init() can return null on unknown streamId. If we have a junk transport stream in our content an exception will be thrown.
*** Reason for rollback ***
Flag doesn't enforce what it says it enforces, due to redirects
*** Original change description ***
Add REQUIRE_HTTPS flag
Note that it's not possible for the library to enforce that
the flag is adhered to, since it's possible for applications
to inject custom implementations of DataSource (there's no
requirement they even extend HttpDataSource for network
requesting implementations). It's possible for applications
to replace pretty much anything in the library, so there's
no other place we could put the flag where we could make
this guarantee. Hence this is a best-effort that will work
when...
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136583459
This is a problem when two invocations of getNextChunk that retrieve
chunks (i.e. not playlists) occur too apart in time. In that case
the last loaded chunk has a media sequence that is behind the current
playlist.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136501291
Note that it's not possible for the library to enforce that
the flag is adhered to, since it's possible for applications
to inject custom implementations of DataSource (there's no
requirement they even extend HttpDataSource for network
requesting implementations). It's possible for applications
to replace pretty much anything in the library, so there's
no other place we could put the flag where we could make
this guarantee. Hence this is a best-effort that will work
when using HttpDataSource implementations that we provide.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136500947
Use sha1 of content uri if a custom cache key or content id isn't provided.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136351830
One issue with the previous implementation was that
isUnsynchronized would not be set back to false if
previously set to true and if the next header has
majorVersion >= 4. In general, having the decoder be
stateless is clearer (and thread safe, albeit that
this property is not required).
1. HttpMediaDrmCallback.executeProvisionRequest needs to specify
an empty byte[], else we do a GET instead of a POST.
2. Content-Type should not be set when making the provision
request, since there's no body.
3. DataSource implementations must correctly handle a non-null
body with zero length. CronetDataSource was not handling this
case. DefaultHttpDataSource was, but made a code modification
to make it a little clearer. OkHttpDataSource seems to handle
the case correctly, and it doens't look like the code can be
made clearer.
Issue #1925
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136042641
Note that actually handling CEA-708 is not yet implemented,
and so this is a no-op change from a behavior point of view.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136038439
The method track(int id) currently has different behaviours across
implementations. This CL maps ids to track outputs, which means
that successive calls with the same id will return the same
TrackOutput instance. Also fixes TsExtractor inconsistent behavior
after a seek.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=136026721
A blocking call is necessary where we want to guarantee that
the player wont access the surface after the method call has
returned. We currently only do this for the case:
Surface->Null
But we should also do it for the case:
SurfaceA->SurfaceB
Since the caller may reasonably do something like destroy
SurfaceA immediately after it's been replaced.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135921296
This allows the injectable reader factory to be a stateless factory, allows
the seeking to be consistent and will allow multiple CC channel support later
on.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135909712
- 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
playingPeriodHolder can be null in the case that the first
period is still being prepared. We need to make sure we
release the period that's being prepared in such cases,
which is loadingPeriodHolder.
Issue: #1914
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135793472
- Move nearly all logic onto the calling thread (i.e. the thread
calling open/read/close), to make threading correctness more
obvious.
- Document which variables are read/written from which thread, and
why the call sequences are safe.
- Fix thread safety issue that I think could probably cause data
corruption in the case of a read timeout followed by another
request into the DataSource.
Also:
- Relaxed content length checking to be consistent with the other
http DataSource implementations, and avoided parsing the headers
where they're not used.
- Fixed missing generics in CronetDataSourceFactory.
- Added TODO to work with servers that don't support partial range
requests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135702217
- Make sure no events are posted on PlaybackControlView
if it's not attached to a window. This can cause leaks.
The target hide time is recorded if necessary and
processed when the view is re-attached.
- Deduplicated PlaybackControlView.VisibilityListener
invocations.
- Fixed timeouts to be more intuitive (I think).
- Fixed initial visibility of PlaybackControlView when
used as part of SimpleExoPlayerView.
- Made some more attributes configurable from layout xml.
Issue: #1908
Issue: #1919
Issue: #1923
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135679988
- Lots of misc cleanup
- Remove GaplessInfo from Metadata. IMO it doesn't quite belong there,
and means it ends up being represented twice inside Format.
- Note: Changes untested, but will be tested in due course!
Without this developers which reuse a SurfaceHolder with multiple instances of
SimpleExoPlayer need to call simpleExoPlayer.setVideoSurfaceHolder(null) to get
the SimpleExoPlayer.ComponentListener removed from the surface holder. If they
don't, the component listener is still registered and as a member class leaks
an instance of simpleExoPlayer.
Issue #1855
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135292439
Playback would fail if a renderer is toggled from consuming from
one child to another in a single step.
Issue: #1900
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135270356
https://github.com/google/ExoPlayer/issues/1827
Three different modes available: fit (default), fixed_width, fixed_height
Developers need to use wrap_content for the dimension which is not fixed:
app:resize_mode="fixed_width"
android:layout_width="320dp"
android:layout_height="wrap_content"
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135264861
Configuration of retry currently fails if all of the
following are true, which is highly unlikely but does
occur in the ref'd issue.
1. Loading/extraction fails
2. Neither length of stream of a seek map is known
3. At least one track has been output by the extractor
Issue: #1899
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135228687
- Enfroce read returns 0 if readLength==0 everywhere.
- Fixes and simplifications for CronetDataSource.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135138232
- Make read return 0 if readLength==0
- Return RESULT_END_OF_INPUT properly in the case that
bytesRemaining is unset (this was broken previously,
but only applies for assets > 2^31 bytes, so it's
unlikely anyone ever hit this issue)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135136541
- Correctly null out streams[j] in the case that a renderer
is being disabled.
- Read discontinuities from all children, not just enabled
ones. This fixes a failure when reading a discontinuity
with all renderers disabled.
- Add in some assertions to make incorrect stream selection
failures obvious and immediate.
- Relocate subtitles so they're above the shutter (needed so
they continue to be visible when video is disabled but
text is still enabled).
Issue: #1854
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135089944
This CL adds support for initialization segments in HLS. This is required mainly for(but not limited to) usage of fMP4. The fMP4 support only consists in creating the required extractor if the extension is .mp4, provided the initialization segment is correctly
loaded and passed to the extractor.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134997636
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
- Fix NPE issue in SingleSampleMediaPeriod.
- Delay handling of EOS in TextRenderer until the last
subtitle is fully played out.
Issue: #1882
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134979286
Currently this has only been tested with the RawCC container, though it should work with anything that makes use of SeiReader (i.e. MPEG2-TS) with minimal changes to SeiReader.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134781660
When reading the last period, the readingPeriodHolder was set to null in
updatePeriods if it was the last period. (This would occur almost immediately
when playing a single-period source.) seekToPeriodPosition suppresses reusing a
loaded/prepared period if the reading period and playing period did not match,
which meant that the whole timeline was recreated when seeking in the last
period.
Leave readingPeriodHolder non-null. This means that at all times either
playingPeriodHolder == readingPeriodHolder (and they could be null or
non-null), or playingPeriodHolder and readingPeriodHolder differ and are both
non-null.
Also fix an issue where streams were never forced to be recreated during track
reselection when reading ahead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134774238
All of the classes in the text.eia608 package have been moved to
text.cea, and renamed with the "cea" prefix instead of "eia". All of
the buffering logic has been extracted from Cea608Decoder (formerly
Eia608Decoder) into the abstract CeaDecoder, which Cea608Decoder
extends. Cea608Decoder also now expects a 3-byte sample (i.e. the
entire cc_data_pkt instead of just the cc_data_1 and cc_data_2 bytes).
Classes like RawCcExtractor and SeiReader, responsible for creating
these samples, have also been updated accordingly.
This change is a necessary precursor to adding support for multi
-channel CEA-608 and CEA-708 captions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134537482
This encourages a single invalidation when setting different parameters.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134436136
HlsSampleStreamWrapper and ExtractorMediaPeriod would call
onPrepared/onSourceInfoRefreshed from their loading threads. That was
problematic for ConcatenatingMediaSource and MergingMediaSource, which assume
that their callbacks are called on the same thread (iterating through timelines
from all sources and updating pendingTimelineSources respectively). This change
makes them post calls to the callbacks on the playback thread.
Generally, implementing a composite MediaSource is easier if
MediaPeriod.Callback's methods are all called on the same (playback) thread, so
this change makes that part of its contract.
Also post onContinueLoadingRequested from ExtractingLoadable because
MergingMediaPeriod.onContinueLoadingRequested reads trackGroups written on the
playback thread.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134407280
Eia608Decoder.
Full preamble positioning will be provided in a subsequent CL. This CL
also contains some minor cleanup in Eia608Decoder and adds some TODOs
to handle the second channel.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134299337
This solves the thread unsafety issue of the default track selector and
allows atomic configuration changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134288525
Also add a test MP3 stream with one frame.
Make FakeExtractorInput's end of input detection to apply also for peekFully, and
make its skip and read methods read at least one byte.
Issue: #1732
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133241641
The four-arg constructor didn't exist in ViewGroup for
earlier API levels. I think it can probably be safely
omitted, unless you know otherwise?
Issue: #1820
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133156975
If a Webvtt HlsChunkSource got to schedule its chunk load before the
master HlsChunkSource (the one that downloads the TS or the fMP4
chunks), the player would never get past the buffering state.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132985792
- Also make some of the naming more concise + misc style cleanup.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132899979
- Also fix an issue that allowed blacklisting of all tracks,
due to incorrect index being used.
- Also fix an issue with track deselection for HLS.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132882151
This allows the adjustment of timestamps in microseconds along with
TS timestamps. This is useful for containers that include the
timestamps in microseconds format, like fMP4 and WebVTT.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132547521
- 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
Adds a few unused fields to HlsUrl and moves things towards the Hls
reimplementation we are looking for. Also fixes a bug related to
asuming every getNextChunk().loadable == null being related to
reaching the live edge.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132305206
If the live window has a small duration, we currently
end up setting the default start position to be right
at the start of the window. This increases the chance
of a BehindLiveWindowException.
With this change we impose a minimum 5s gap between
the start of the window and the default start position.
If the window is *really* small (<10s) then doing this
would push the default start position too close to the
end of the window. We don't have much time to play with
in either direction in this case, so we put the default
start position in the middle of the window and hope for
the best.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132054802
Now you can do cool things (if you really want to!) like
play a video twice, then play a second video, then loop
the whole thing, all seamlessly.
new LoopingMediaSource(
new LoopingMediaSource(firstVideoSource, 2),
secondVideoSource));
You can also just loop, which is probably more useful :).
Issue: #490
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132049599
People will inevitably try and do it, and it's pretty
easy to handle properly, so why not...
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132047019
- Don't send a timeline to the listener until all children
have reported their timelines.
- Propagate a proper merge error if merging fails.
- The PlayerActivity hack is necessary due to the way Andorid's
MediaController widget attaches to the window :(. It'll go
away once we get our own player controls.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131958169
This could cause us to "lose" allocations backed by an
initial block, meaning they became unavailable for use
despite still being allocated.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131931465
- The need to pass a Clock is pretty much only for testing, so
make the constructor that takes one package private + use
the system clock for public constructors.
- Add default timeout values.
- Also make sure we set Content-Type in all license requests,
since when using Cronet the stack requires it to be set.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131404298
This is done through the bitstream id field and allows removing
the isEac3 parameter from the constructor.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131393477
If they're omitted, it's reasonable to assume it's because
they were uninteresting (i.e. sample data always tightly
packed at the start of the mdat). This is an issue for some
SmoothStreaming streams.
We actually already play such streams successfully, but
that's only due to another bug to be fixed in a following CL.
The same is true for V1, but given the low impact nature,
the fix will be V2 only.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131191975
If currentTrackBundle is updated at the start of the
block and then something goes wrong in the middle (e.g.
one of the skipFully calls) then the extractor wont
resume from the correct place.
This would be caught by our extractor tests if we had
a test sample that requires skipping to the sample data.
I'll try and construct one of those.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131191174
- The -1 needs to be a 0. My bad.
- Create AAC CSD if not defined in manifest, like in V1.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131190995
Also tweak how the null checks happen in a few DataSource
implementations (should be no-op changes, but allow you
to look at close() and be happy it does the right thing
without having to loop at the open() implementations).
Issue: #1759
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131172427
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
Fix the calculation of the seek window for multi-period DASH.
Snap the default initial position back to the start of its segment, to ensure
that the first sample provided when transitioning to a DASH live source is a
key-frame.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131052912
- Remove playingPeriodEndPositionUs. It doesn't look like it's
required.
- Rename time variables to make it clearer what they are.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131027164
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
Also inline a few methods/classes where they can be made
private and therefore be removed from the public API.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130935090
Mainly, this allows the extractor to expose multiple audio tracks.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130928152
