1112683 - MP4 video pauses buffering for ~15 seconds before audio starts to play

Status: NEW

(Core :: Audio/Video: Playback, defect)

Description

[Chris Peterson [:cpeterson]]

Attachment: browser-content-toolbox-open.mp4

When I play these videos in Firefox 34, Firefox uses the QuickTime plugin and the videos play immediately, as expected. When I play them in Beta 35, Aurora 36, or Nightly 37, Firefox plays about 1 second of video, pauses for ~40 seconds, then plays audio and video together. In Chrome, the videos play immediately, as expected.

https://dl.dropboxusercontent.com/u/91815060/browser-content-toolbox-open.mp4
https://dl.dropboxusercontent.com/u/91815060/browser-content-toolbox-using.mp4

When loading the video, Firefox prints the following message to stdout:

> I/SampleTable(49518): There are reordered frames present.

* cpearce: would you like me to bisect the problem further than just "problem starts in Firefox 35"?

Comment 1

[Chris Peterson [:cpeterson]]

cpearce: would you like me to bisect the problem further than just "problem starts in Firefox 35"?

Comment 2

[Ralph Giles (:rillian)]

I can reproduce with the dropbox links, but not the attachment nor when playing a copy of the dropbox file off the local disk.

Seems to be a network interaction. It takes a long time to show any buffered data, and we don't start playback until the buffered level is moving along nicely. When I wget the file from dropbox, download seems to ramp up normally.

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

I expect that you're seeing a network issue.

We will start playing the video once we think that the download speed is such that we can start playback bad the decode won't catch up with the download. I suspect you're seeing the download speed "burst" at the start, and then trail off, and that's why we're stopping and then starting to buffer.

Chrome doesn't do this rate estimation. They just start playback as soon as the download begins, and they get away with it most of the time. I suspect this is what you're seeing. Do you see the same behaviour when using desktop Firefox on a different OS/computer? That would point to a network issue.

Comment 4

[Chris Peterson [:cpeterson]]

(In reply to Chris Pearce (:cpearce) from comment #3)
> I expect that you're seeing a network issue.

I suspect you are correct. I was not able to bisect the problem because the buffering delay varied; it was consistently 40 seconds yesterday, but only about 10 seconds today.

> Chrome doesn't do this rate estimation. They just start playback as soon as
> the download begins, and they get away with it most of the time. I suspect
> this is what you're seeing. Do you see the same behaviour when using desktop
> Firefox on a different OS/computer? That would point to a network issue.

I have a 50 Mbps cable internet connection and see the same behavior with Wi-Fi and wired ethernet, so I wouldn't expect bandwidth to be a limitation. However, my ISP (Comcast/Xfinity) boasts about their "patent-pending 'PowerBoost' network technology", which "provides bursts for the first 20 MB downloading a file".

Could Comcast/Xfinity's initial burst confuse Firefox's rate estimation?

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Chris Peterson (:cpeterson) from comment #4)
> Could Comcast/Xfinity's initial burst confuse Firefox's rate estimation?

Yep, sure could. You might investigate some kind of traffic shaping to help reliably reproduce this.

Comment 6

[Chris Peterson [:cpeterson]]

I see a similar 10–20 second hang when I seek ahead (of the buffered section) on the following video. Chrome seeks ahead without delay.

https://store.playstation.com/#!/en-us/games/pier-solar-and-the-great-architects/cid=UP2122-NPUB31476_00-HDDBOOT000000001

To rule out Comcast/Xfinity's "PowerBoost" confusing Firefox's rate estimation, I connected to my phone's Wi-Fi hotspot to use T-Mobile's LTE network (~30 Mbps, which is comparable to my cable internet). I still saw 10–20 second hangs.

Comment 7

[Chris Peterson [:cpeterson]]

Attachment: MediaDecoder.log

Ralph, is this debug log useful? I can still reproduce this problem in Nightly 41.

Here is a debug log of NSPR_LOG_MODULES=MediaDecoder:5. I held down the Return key when the video was buffering so the large sections of whitespace show where the MediaDecoderStateMachine was spinning.

The first video frame start is 66666, but first audio frame start is 0. Is having a different video and audio frame start times unusual?

The state machine bounces between BUFFERING and DECODING states. It repeatedly buffers for about 0.814s, plays 1024 frames of audio, decodes for about 0.036s, and then blocks in the NEXT_FRAME_UNAVAILABLE_BUFFERING state. The playback rate then was 191.7KB/s and download rate 1324.1KB/s so the network doesn't seem to be a bottleneck.

Comment 8

[Ralph Giles (:rillian)]

Probably. I've not been looking at this code lately. Jean-Yves, does this look familiar to you? Work any better with your new code?

Comment 9

[Chris Peterson [:cpeterson]]

When I originally filed this bug (for Firefox ~35), the buffering pause was about 40 seconds. Now (testing Nightly 41) the buffering pause is "only" about 10–15 seconds.

Comment 10

[Jean-Yves Avenard [:jya]]

Sounds like a consequence of bug 1131884 (change of timeout value that is)

Having a different audio/video start time won't cause this. It's very common actually for video and audio to not start exactly at the same time (Especially as PTS weren't properly calculated in some MP4)

Sounds like bug 1131884 didn't fix all problems.

Comment 11

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Is this still an issue?