Video freezes when changing quality into MSE SourceBuffer
Reported by
bertrand...@orange.com,
Oct 6 2016
|
|||||
Issue descriptionExample URL: http://w3c-test.org/media-source/mediasource-config-change-mp4-v-framesize.html Steps to reproduce the problem: 1. Play adaptive stream with MSE 2. Push intialization and data segments into SourceBuffer 3. Push intialization and data segments of a different quality (= different H.264 decoding parameters) into SourceBuffer What is the expected behavior? What went wrong? Video freezes and playback stops. The problem happens only on some Android devices. But on these same devices, it works with Firefox and Opera. I guess all these browsers use GPU video decoder, so why it fails when using chrome? Did this work before? N/A Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Yes Chrome version: 53.0.2785.124 Channel: n/a OS Version: 4.4.2 Flash Version:
,
Oct 10 2016
I can repro this bug. The test does stall in the middle. bertrand.berthelot@orange.com, does this test ever pass on Android OS before?
,
Oct 11 2016
Yes. This test pass on some Android devices with OS version 4.4.2, but not on some others. Maybe there are some bugs on these devices with the hardware video decoding, but it works with firefox and safari.
,
Oct 18 2016
Thank you for providing more feedback. Adding requester "yiningc@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 18 2016
Matt, this bug repro on Android 5, 6 but not repro on Android 4. Since we changed a lot since Android 4, I suspect it is by design. Can you confirm?
,
Oct 24 2016
tl;dr: media on Chrome for Android requires a user gesture for playback in many cases; our test infra disables that requirement. Manually running such a test still needs that user gesture to commence playback (otherwise test fails). This is WAI. Initially, there were three items considered as possible causes for this: 1) upstream w3c wpt tests for mp4 were adjusted to work on FF, but not with Chrome MSE which still conflates mp4 dts and dts. Since this test passes on current desktop (linux) M54, and there haven't been other dts/pts changes to Chrome in M53->M54 IIRC, then this is actually not a likely culprit. 2) Spitzer (unified Android media pipeline) went 100% in M52, replacing the previous fork of the decode/render/compositing path on Chrome for Android with one that better matches our desktop Chrome media architecture. 3) User-gesture requirement for playback start on Chrome for Android, by design. I strongly suspect #3. I confirmed it's #3 using adb logcat and repro on Nexus 6P. Log entry shows: 10-21 11:16:30.712 I/chromium(14030): [INFO:CONSOLE(104)] "Failed to execute 'play' on 'HTMLMediaElement': API can only be initiated by a user gesture.", source: http://w3c-test.org/media-source/mediasource-config-changes.js (104) I then confirmed with locally copied and adjusted version of that Example URL to include the "controls" attribute on the <video> element, and observed that tapping the element's "play" control during a run of this test enabled it to pass. We work around this in our layout test automation by using special cmdline parameters and content_shell such that the gesture requirement is disabled in that automation. Granted, that automation runs on the downstream set of these tests, but they should catch a real regression that's unrelated to the user gesture requirement. Chrome for Android appears to be WAI. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by rsgav...@chromium.org
, Oct 6 2016Labels: triage-te