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
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
This is a minor cleanup. The main thing it fixes is that
the "Inconsistent headers" and "Unexpected Content-Range"
log messages were printing List<String> objects, rather
than the actual headers they are supposed to print.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135378074
The access in fillCurrentRequestPostBody wasn't protected with
synchronization. Furthermore, just synchronizing it wouldn't be
sufficient, since what we really need to check is whether the
Content-Type header has been added to the UrlRequest.Builder.
The contents of requestProperties may have changed between the
headers being added to UrlRequest.Builder and the call to
fillCurrentRequestPostBody.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135376904
- Allow null Content-Type in response headers.
- Inline validateResponse, just because it makes it clearer
what thread it's being executed on when inlined.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135375063
- Fix bug in getCurrentRequestStatus where we weren't
blocking on the condition variable.
- Make methods static where possible.
- Clean up getUri implementation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135373586
This change is a no-op reodering, as a precursor to
further cleanup. The public methods are grouped by
the class/interface they implement. The private methods
are ordered with things that will become static in
a subsequent change at the bottom.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135372629
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
