HTML5 mp4 video hangs on play with preload="metadata"
Reported by
anand.te...@gmail.com,
Sep 19 2016
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 Example URL: https://jsfiddle.net/t9w04Lmn/ Steps to reproduce the problem: 1. Open chrome 2. Clear the cache 3. Open the url https://jsfiddle.net/t9w04Lmn/ 4. Click on the video to start playing once it has loaded What is the expected behavior? Video should play. What went wrong? Video only plays the first frame and hangs after that 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.116 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0 This is not a consistent repro and happens more often on clearing/diabling cache. Looking at network trace, chrome makes a range request to get the initial metadata and gets few hundred kb of data and terminates the connection. On video play it opens another connection with different value for range header but only gets few kb data (sometime this connection is never started). After this the video is stuck at 0:00 and buffering value never increases (remains close to 0.6 seconds) On few retries, we noticed that the first connection does not always download the same amount of data and this issue happens more often when less data is downloaded on first request. This issue does not repro with preload set to "auto" or "none". This is happening on previous versions of chrome as well.
,
Sep 19 2016
+sandersd, hubbe
,
Sep 20 2016
,
Sep 21 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3b2a5629da155db59d3449a6d640c107e91aa14d commit 3b2a5629da155db59d3449a6d640c107e91aa14d Author: hubbe <hubbe@chromium.org> Date: Wed Sep 21 07:17:46 2016 Fix a timing bug in multibuffer. When "cancel on defer is on", the multibuffer reader can sometimes get delete before it is allowed to deliver a pending read callback. This basically hangs the multibuffer data source as it waits for the read callback forever. BUG= 648395 , 647867 , 646434 Review-Url: https://codereview.chromium.org/2357773003 Cr-Commit-Position: refs/heads/master@{#419995} [modify] https://crrev.com/3b2a5629da155db59d3449a6d640c107e91aa14d/media/blink/multibuffer_data_source.cc [modify] https://crrev.com/3b2a5629da155db59d3449a6d640c107e91aa14d/media/blink/multibuffer_data_source.h [modify] https://crrev.com/3b2a5629da155db59d3449a6d640c107e91aa14d/media/blink/multibuffer_data_source_unittest.cc
,
Sep 21 2016
Fixed, and verified in a ToT build. Once it's been verified in a canary build, we can backport the fix.
,
Sep 22 2016
The fix is in todays canary build. Anand, can you verify that this works for you on chrome canary?
,
Sep 22 2016
Hi Hubbe, thanks for the quick turn around on this bug. We tried today's canary build and videos are playing fine. Did not see the issue happening.
,
Sep 22 2016
,
Sep 22 2016
Your change meets the bar and is auto-approved for M54 (branch: 2840)
,
Sep 22 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b39d634c0efdd5912bfca4336ba9dc908e67fe10 commit b39d634c0efdd5912bfca4336ba9dc908e67fe10 Author: Fredrik Hubinette <hubbe@google.com> Date: Thu Sep 22 22:36:17 2016 Fix a timing bug in multibuffer. When "cancel on defer is on", the multibuffer reader can sometimes get delete before it is allowed to deliver a pending read callback. This basically hangs the multibuffer data source as it waits for the read callback forever. BUG= 648395 , 647867 , 646434 Review-Url: https://codereview.chromium.org/2357773003 Cr-Commit-Position: refs/heads/master@{#419995} (cherry picked from commit 3b2a5629da155db59d3449a6d640c107e91aa14d) Review URL: https://codereview.chromium.org/2362953002 . Cr-Commit-Position: refs/branch-heads/2840@{#500} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/b39d634c0efdd5912bfca4336ba9dc908e67fe10/media/blink/multibuffer_data_source.cc [modify] https://crrev.com/b39d634c0efdd5912bfca4336ba9dc908e67fe10/media/blink/multibuffer_data_source.h [modify] https://crrev.com/b39d634c0efdd5912bfca4336ba9dc908e67fe10/media/blink/multibuffer_data_source_unittest.cc
,
Sep 28 2016
Verified the issue on windows 10 using chrome beta version #54.0.2840.41 as per comment #0 Observed that the fix is working as expected. Attaching screencast for reference Hence, adding the verified labels
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b39d634c0efdd5912bfca4336ba9dc908e67fe10 commit b39d634c0efdd5912bfca4336ba9dc908e67fe10 Author: Fredrik Hubinette <hubbe@google.com> Date: Thu Sep 22 22:36:17 2016 Fix a timing bug in multibuffer. When "cancel on defer is on", the multibuffer reader can sometimes get delete before it is allowed to deliver a pending read callback. This basically hangs the multibuffer data source as it waits for the read callback forever. BUG= 648395 , 647867 , 646434 Review-Url: https://codereview.chromium.org/2357773003 Cr-Commit-Position: refs/heads/master@{#419995} (cherry picked from commit 3b2a5629da155db59d3449a6d640c107e91aa14d) Review URL: https://codereview.chromium.org/2362953002 . Cr-Commit-Position: refs/branch-heads/2840@{#500} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/b39d634c0efdd5912bfca4336ba9dc908e67fe10/media/blink/multibuffer_data_source.cc [modify] https://crrev.com/b39d634c0efdd5912bfca4336ba9dc908e67fe10/media/blink/multibuffer_data_source.h [modify] https://crrev.com/b39d634c0efdd5912bfca4336ba9dc908e67fe10/media/blink/multibuffer_data_source_unittest.cc
,
Dec 12 2016
Issue 648390 has been merged into this issue. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by anand.te...@gmail.com
, Sep 19 2016118 KB
118 KB View Download