Reintroduces the play/pause rebuffering logic we eliminated
in JB zero day to fix double spins and slow startup - but
activates that logic only based on a comparison of the
current bandwidth measurement and the lowest bitrate track
in the movie.
Needs to be submitted with related changes in /frameworks/av
bug: 7230071
Change-Id: Ib3859a961bd3901a9c4df01eeab2b8b75f49aefe
This change updates the Widevine binary libraries.
It includes the change:
https://widevine-internal-review.googlesource.com/1400
Cleaned Up Locks and Removed Pause/Resume
bug: 6799914
Change-Id: I5e266e4d8bdc92e88e488d90aa5312ac740303b0
The FATAL EXCEPTION is caused by the decrypt function returning -EINVAL
when OEMCrypto decrypt returns an error. The fix is not to call
OEMCrypto decrypt when eos is reached.
related-to-bug: 7216928
related-to-bug: 7217609
Change-Id: I8f006905386e2cdfb907d4ab15c766ae69f20f00
Signed-off-by: Iliyan Malchev <malchev@google.com>
This allows a DRM client to open a locally-cached file on behalf of the
DRM server so the DRM server no longer requires the sdcard_r permission
to access the file's metadata. Specifically, this adds an optional
attribute FileDescriptorKey to the DrmInfoRequest.
This change is dependent on this Widevine CL:
https://widevine-internal-review.googlesource.com/#/c/1330/
Relevant bug reports:
bug: 6426185
Change-Id: Ia7bcb2455c7a55fa4c7c7061de4d672957c7ac0a
There was a subtle interaction between Widevine's libraries and MediaCodec
mode. Widevine's code assumed (erroneously) that video seeks would always
happen before audio seeks, and because we can't seek audio and video
independently from each other, we would ignore audio seeks but respect video
seeks. This led to a problem since MediaCodec mode calls seeks in arbitrary
order.
Fix is to always respect the first request we get to seek and ignore the
second.
Bug: 6793514
Change-Id: Ic9ec60e0e0f606c7a0de6283dd4c30318eebdbad
In order to test the MediaPlayer info events, an OnInfoListener was added to
the VideoPlayerView class. It is set to listen to events coming from the
videoView. This allows testers to verify that events are occuring.
Note: This change was made by Alexander Oliphant who does not have write
permission to commit to the Android tree.
Change-Id: Ia2faa927b4fe2850e15644bd332e50601a424c4a
Error code from the plugin is not propagated from WVMExtractorImpl.cpp to the MediaPlayer.
The two APIs addresses this issue and provide a path for the player to retrieve the last error.
Change-Id: I60040eaf2d396379eecca46bfe333c44a39c35ec
related-to-bug: 7073630
Widevine Library for Level 1 and 3: Version 4.5.0.10079 AES 601_AndroidOS_J
This library has the following changes:
https://widevine-internal-review.googlesource.com/1320
Fix multicore synchronization issue in Pump.cpp
https://widevine-internal-review.googlesource.com/1343
Call OEMCrypto_Terminate in DRM Plugin After Setup. (JB MR1)
related-to-bug: 7078790
related-to-bug: 7092908
related-to-bug: 6769768
Change-Id: I4a03b60a1f030d710a2b2dd7f2a1ac3746ec846b
Because Widevine's libraries were not seeking to the start of playback, the
first bitrate track in the video was being selected rather than the most
bandwidth-appropriate. For low-bandwidth connections, this could lead to a
"locked to group-of-pictures" scenario where Widevine quickly realizes that it
needs to change bitrates but cannot change until the next I-frame, which at the
current bandwidth will not arrive before it runs out of data. The result is
frames being delivered late, leading to the "Much Too Late" message from
AwesomePlayer reported in the bug.
The solution is to start playback slightly differently, allowing us to use our
adaptive streaming logic to select the initial bitrate for the video. By
specifying a start point at the beginning of the movie instead of just "now,"
we cause a seek internally, which allows us to adapt bitrates immediately at
the start of playback rather than after it has begun. This is the common way
of starting playback on other Widevine platforms. Android has been an
exception until now.
Bug: 6621556
Change-Id: Iaf98106f7f597ae3f0375129ac3a93aa3cb04a2c