This requires knowing the seek time in Extractor.seek, so that it's possible to
pick the latest synchronization sample at/before the seek time for each track
(rather than the earliest synchronization sample after the seek position).
Also remove the STATE_AFTER_SEEK state which should no longer be needed.
Issue: #2167
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=141432598
This is the second CL in the 3 CL process to switch Cronet versions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=140074017
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
*** 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
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
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
- 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
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
- 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
It'll be a TODO to clean up some of the commonality between
publishing this and the core library (e.g. the version number
should really be spec'd in one place only). Just getting this
submitted for now so that we don't lose track of how I created
https://bintray.com/google/exoplayer/extension-okhttp
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=135102459
If/when we add the ability to query version information,
such methods will go into FlacLibrary for consistency with
the other extensions. The difference for Flac is that
since the decoder JNI is used by the extractor too, it
needs splitting into a separate from from FlacDecoder.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132904665
- Also make some of the naming more concise + misc style cleanup.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=132899979
- 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
- Centralise compileSdkVersion, targetSdkVersion and
buildToolsVersion in a single place for gradle.
- Bump compileSdkVersion and targetSdkVersion to 24.
- Bump com.android.tools.build version to re-enable
instant start.
- Bump targetSdkVersion in manifests (needed for
internal builds).
- Use standard expandable_list_item from Android in
the demo app, since ours doesn't look right when
targeting API level 24. We were also setting the
theme on the wrong element in the manifest, so I'm
removing that line.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=131929216
