Widevine Delivers Frames "Much Too Late" On Startup
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
This commit is contained in:
@@ -132,7 +132,7 @@ status_t WVMMediaSource::start(MetaData *)
|
||||
// Let video stream control play/pause
|
||||
if (mESSelector == WV_EsSelector_Video) {
|
||||
float speed;
|
||||
WVStatus result = WV_Play(mSession, 1.0, &speed, "now-");
|
||||
WVStatus result = WV_Play(mSession, 1.0, &speed, "00:00:00-");
|
||||
if (result != WV_Status_OK) {
|
||||
ALOGE("WV_Play returned status %d in WVMMediaSource::start\n", result);
|
||||
return ERROR_IO;
|
||||
|
||||
Reference in New Issue
Block a user