Issue metadata
Sign in to add a comment
|
MSE keeps playing upto ~3sec more audio than video when there is audio overrun
Reported by
sanja...@yahoo-inc.com,
Feb 1 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: I am loading fragmented mp4 video & audio in two different MSE sourcebuffers such that both audio and video are loaded and appended to buffer independently. Sometimes, when amount of audio appended is more than the video, audio keeps playing while video is paused. 1. Host the attached 'indexFMP4.html" on a local server. 2. I am using Apple’s fragmented MP4 example - ( https://developer.apple.com/streaming/examples/advanced-stream-fmp4.html) Since, accessing it results in CORS issue, I am hitting through a proxy server which runs on port (:5000). This can be changed to any other proxy server. 3. Now check the html page in Chrome and let the content play till end. What is the expected behavior? Even though amount of audio appended is more than the video, both audio and video should stop at same time and current time should stay within the buffered range of HTML5 video node. What went wrong? As shown in the html page, if more audio is appended it keeps playing upto ~3sec though the video has stopped. As shown in console logs, current time goes upto ~18sec while the end of buffered range of HTML5 video node is ~15sec. Therefore, current time moves beyond the buffered range. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 55.0.2883.95 Channel: n/a OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 24.0 r0 Note: This issue doesn't happen if video is overrun. If you load more video in the attached html page, both audio and video stop at the same time. Attached screenshot shows both cases.
,
Feb 3 2017
,
Feb 3 2017
This is working as intended since we've shown that users are more accepting of video underflow than audio underflow. Is there a specific issue that's arising because of this?
,
Feb 6 2017
Can we close this issue, or is there any feedback we are waiting on from reporter?
,
Feb 6 2017
Hi, Thank you for the reply. The issue here is when we are filling the two mse sourcebuffers (audio and video) at different rates, then audio buffer can fill at a faster rate. Now if the play head reaches the end of the video buffer, we want the video to rebuffer instead of continuing to play more audio. In cases of not so good networks when there is lot of rebuffering, video buffer should be given enough time to catch up with audio. Also, shouldn't the current time always stay within the video node's buffered range? In this case it goes ahead. We see both audio and video buffer stopping together in all the other browsers.
,
Feb 13 2017
,
Feb 24 2017
sanjauli@yahoo-inc.com, can you provide a repro url?
,
Feb 27 2017
Hey Yinning, no need for a repro URL for this bug. This issue is well understood and this bug is another data point in favor of modifying this behavior. I have a proposed fix for this here: https://bugs.chromium.org/p/chromium/issues/detail?id=593271#c17 But I have not had time to implement yet. Will resolve this a duplicate and continue looking for time to fix.
,
Feb 28 2017
Hi Yinning, In case needed, I had attached the test page (indexFMP4.html) which can reproduce this issue. The steps to reproduce are present in test page and in the description above. Please let me know in case any additional details are required. chcunningham@chromium.org: I will keep a track of the original issue which was reported. Thanks. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by sanja...@yahoo-inc.com
, Feb 1 2017480 KB
480 KB View Download
4.1 KB
4.1 KB View Download