That file (a) was always forced upon you anyway and (b) no longer
exists.
Change-Id: I5964a0420e9114419b62d5b98e7ecef6c5b48296
(cherry picked from commit c2d4ae15fbbb4ebee364449cf9693566e10d07a1)
* Move some libraries that were being built with the NDK but
statically included into platform code off the NDK.
* Update the prebuilt Widevine Classic binaries to 4.5.0.10131.
Bug: 15193147
Change-Id: I93f356a97c9c92c1f14c00e7420b941b1bb4357e
This project is still using stlport (without telling the build system
about it), which was causing (broken) stlport headers to override
libc++ headers, leading to a broken copy of std::enable_if, which in
turn caused <atomic> to fail to compile. Since this project has
prebuilts that will need to be updated before this project can
actually move away from stlport, tell the build system that it is
still using stlport for now.
Bug: 18433002
Change-Id: I38b356428977ed2184eb28a07bd5e7424a4ace8d
(cherry picked from commit de4bc34719)
Support builds for multiple architectures the same time:
Use LOCAL_MODULE_TARGET_ARCH to restrict building to specific arches
Use LOCAL_C_INCLUDES_x86 to set the include path for only x86 builds
Change-Id: I7c33c27f1c9bfb6e3318a07514698992482f6cd7
Some OEMCrypto calls are happening before OEMCrypto_Initialize.
This change moves initialization earlier so it occurs before
any other calls to OEMCrypto.
bug: 10582250
Change-Id: Ic8992e8f0738dbfeb10074a4e1543bb9931a49d5
When the video packets are clear, they are being
combined into a full frame between MediaExtractor or
DecryptCallback (where packets are never > 64k) and
MediaCrypto/DecryptVideo (where we are seeing clear
packets > 64k).
The max block size to be passed to DecryptVideo is
specified as 64K, handling of packets larger than 64K
is undefined and OEM implementation-dependent. In the
Nexus 10 case, it generates a SEG. fault.
Solution:
Add mClearSizes vector to keep track of each clear
packet size for android_media_MediaExtractor_getSampleCryptoInfo()
to process.
In android_media_MediaExtractor_getSampleCryptoInfo(), if it
does not see kKeyEncryptedSizes meta data, it will not
process the clear vector that contains the actual packet
sizes. Add a kKeyEncryptedSizes meta data that contains a zero
length size packet to trick the JNI code to process the
clear packets.
related-to-bug: 9261447
Change-Id: Ib0b655a95e099856babaf649f4a95fc7f9c17d41
Only the first 64K of the movie is pulled when sniffing,
if the widevine version metadata is not present in the
sniff buffer then a "format unsupported" error would occur.
This change increases the sniff buffer size to 128K.
bug: 9351294
Change-Id: If162cbea6915bf2b70122afd30e556e9206e8e43
The solution previously checked in as 2e0e3 is re-introduced here. However,
the MediaCodec-compatible heuristic is not used unless WVM is in Crypto Plugin
(i.e. Media Codec) mode.
To repeat from last time: The problem here is that WVM cannot independently
seek the audio and video read heads, but the API assumes it can. WVM does the
right thing for AwesomePlayer-based playback (essentially ignoring audio
seeks) but the wrong thing for MediaCodec-based playback. For MediaCodec
mode, we should respect the first seek we get for a given destination and
ignore the second.
In this part, the new heuristic is reintroduced, but the old heuristic is
maintained for use in non-Crypto Plugin mode.
Bug: 6793514
Change-Id: I7ced2bf20af117a57eec27490b0920d906a8a684
Change 14f0d to read the maximum buffer size from a device property did not
work correctly on Mako and Prime devices, as they did not have the property
set, and the code to fall back to a default value was not working. An empty
string would be read instead of the default value, resulting in a maximum of
zero. Because Widevine Media Kit would then subtract a few megabytes from this,
it would underflow, giving a maximum buffer size of several gigabytes. This
would lead to the download code trying to pre-buffer the entire, many-gigabyte
movie. As the media server's memory usage grew and grew, other programs would
become starved for memory, leading to most other processes on the phone being
forced to close. Eventually, the playback app, the media server, or some other
crucial piece of functionality would be starved, resulting in a crash.
The fix is to fix how we get the default, so that when the property is not
available, we get a sensible result. We check the return value of property_get.
If it is greater than zero, the property was read successfully, and we parse
the answer. If it is equal to (or less than) zero, we fall back to the default
value.
Bug: 7222769
Change-Id: Ie6186a0533036ab8fa45b1e467611d55f7c345ac
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
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
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
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
The property ro.com.widevine.cachesize may be set on a device to override the
default stream buffer cache size.
related-to-bug: 6819880
Change-Id: I27da154e38289c5d1f5f2f5f424202253d0721cc
Includes Widevine libraries Version 4.5.0.7809
Also fixed samplePlayer's MediaCodec mode not running and
WVDrmInfoRequestStatusKey returning incorrect value.
Change-Id: Ibcc6d313790670a908ada93be80d6bf55a67b4ed
related-to-bug: 6929628
related-to-bug: 6833718
related-to-bug: 6889322
This change alters the way that the media player
interacts with the Widevine adaptive streaming buffer
logic. It eliminates the reliance on cached buffer
duration to determine pause/play states and instead
only generates buffering events when the widevine
library is not producing data (i.e. when it is
buffering). This eliminates unnecessary pause and
rebuffer cycles, reducing startup time and the
frequency and duration of spinners.
Multi-repo commit, depends on related changes in frameworks/av
Change-Id: I5b71f954268fbd390eed7f27db98a1bb470d5cfb
related-to-bug:6503294
related-to-bug:6463780
The function WVMExtractorImpl::getCachedDurationUs returns the cached buffer
size in microseconds, and sets a status to ERROR_END_OF_STREAM at the end of
the movie. The AwesomePlayer will pause if the cache is too small and the
status is not EOS. In bug 6277231, the player would pause just before the EOS
marker would have been seen by the Widevine library.
This change checks the current play time against the total movie duration. If
there is less than 10 seconds left in the movie, the EOS flag is set.
related-to-bug: 6277231
Change-Id: I8dbf60c82c41df485185f85e72452aab0a6a9686
In WVMExtractorImpl.cpp, a structure of type WVCallbacks was not initialized.
In version 4.5.0 of the Widevine library, this is just a struct (not a class)
so it does not have a constructor method. This record was being set with
garbage default values and was causing problems setting up playback. This may
have caused other stability issues after we reverted to 4.5.0. In the future,
when we push forward to version 6.0 of the Widevine library, this change should
be removed.
In WVMediaSource.cpp, a flag was set to strip off the ATDS headers. This was
redundent, and causing seg faults, for live stream.
related-to-bug: 6454710
Change-Id: I3edeb40c731021b2f31f639416188d4a1c002cc5
This change resolves a lifetime issue between the media extractor
and media sources. The extractor was being passed as a context
object to a callout in the WV libs. In some cases, a pointer to
the extractor would be delivered to the callout after the extractor
had been released. This change assigns the responsibility of the
lifetime of the context object to the media source, to ensure that
a ref is always held on the context object during the lifetime of
the media source.
Change-Id: Ic7a57a1c8496a4798fe590ec356b8a19a4f69967
related-to-bug: 6502322
