1224947 - Vimeo video playback stalls, even though the video is buffering

Status: RESOLVED FIXED

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

Description

[Chris Peterson [:cpeterson]]

@ jwwang: I think this is a regression from bug 1223599. I bisected the regression to this pushlog:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ada1afb12a16333d26974328d0f340712f354bf2&tochange=7fbfb74b3dd32634e4cdc314ab9f48eaeaeada6a

STR:
1. Load https://vimeo.com/64895205
2. Press the video's play button.

RESULT:
The video will start buffering, but playback is stalled at time 0:00 or 0:01. If the video *does* start playing, then seek ahead in video a couple times and then playback will stall.

Comment 1

[JW Wang [:jwwang] [:jw_wang]]

The same stall is also observed on Google Chrome if you click the play button immediately after the page is loaded. However, if you wait for a few seconds before pressing 'play', it will play smoothly without buffering.

Btw, the stall can also be observed on Firefox even if I backout bug 1223599.

Comment 2

[Chris Peterson [:cpeterson]]

Do you think this is a bug in the Vimeo video player and not a regression from bug 1223599?

I tried, but I can't reproduce the stall with Chrome on OS X or Windows 8.1. I saw a similar stall with IE11 on Windows 8.1: seeking ahead would render the new video frame, but the video would not play.

I can reproduce with Nightly 45 on OS X and Windows 8.1, but not Aurora 44.

Comment 3

[JW Wang [:jwwang] [:jw_wang]]

I can repro it on Aurora 44 on Linux. I guess it might be a platform dependent issue or some kind of network issue and bug 1223599 should be clean.

Comment 4

[JW Wang [:jwwang] [:jw_wang]]

NSPR logs:
2015-11-16 08:48:54.674857 UTC - 693851904[7fd019a3e1a0]: Decoder=7fd019902840 Video decode isAsync=1 HWAccel=0 videoQueueSize=10

It looks like hard acceleration is disabled and video decoding is very slow.

Hi Chris,
Can you try `NSPR_LOG_MODULES=timestamp:1,MediaDecoder:4 ./mach run https://vimeo.com/64895205` to check if hard acceleration is enabled on your computer? I guess this is what makes the difference.

Comment 5

[Chris Peterson [:cpeterson]]

Attachment: MediaDecoder.log

Here is my MediaDecoder log file. Looks like my HWAccel=0 too:

2015-11-17 05:56:35.316723 UTC - 59699200[13ef7c710]: Decoder=134216560 Video decode isAsync=1 HWAccel=0 videoQueueSize=10

Comment 6

[Chris Peterson [:cpeterson]]

I don't think HWAccel=0 is the problem, because I see the same with Firefox 42, where I can't reproduce the stall.

Comment 7

[JW Wang [:jwwang] [:jw_wang]]

Tried Firefox 42 on Linux, the same stall is still observed. Did you run 42 on Mac?

Comment 8

[JW Wang [:jwwang] [:jw_wang]]

Btw, the seek stall depends on how far away the seek position is from the key frame. If your seek position is close to a key frame, seek will finish quickly. Otherwise, decoder will decode-and-discard several frames in order to get to the seek position and it will be slow (up to 2 or 3 secs on my Linux box).

Comment 9

[Chris Peterson [:cpeterson]]

(In reply to JW Wang [:jwwang] from comment #7)
> Tried Firefox 42 on Linux, the same stall is still observed. Did you run 42
> on Mac?

I tested 42 on Mac and Windows (albeit in a VM). I haven't tested Linux. The video is an mp4 file. Are you using GStreamer on Linux?

Comment 10

[JW Wang [:jwwang] [:jw_wang]]

I tried gstreamer and ffmpeg. Both presented the same stall.

Comment 11

[Chris Peterson [:cpeterson]]

(In reply to JW Wang [:jwwang] from comment #8)
> Btw, the seek stall depends on how far away the seek position is from the
> key frame. If your seek position is close to a key frame, seek will finish
> quickly. Otherwise, decoder will decode-and-discard several frames in order
> to get to the seek position and it will be slow (up to 2 or 3 secs on my
> Linux box).

When I say the video "stalls", I mean that it never plays, not that a seek takes 2–3 seconds to play. Even if I wait for the entire video to buffer and I toggle the play/pause button or seek around, the video never plays.

Comment 12

[JW Wang [:jwwang] [:jw_wang]]

Sorry to got you wrong. How easily can it be reproduced? I never see the permanent stall on nightly on Linux.

Comment 13

[Chris Peterson [:cpeterson]]

I can reproduce the permanent stall very easily (at least 80% of the time) on OS X and Windows 8.1 (in a VM). My current STR:

1. Load https://vimeo.com/64895205
2. Click the video to start playing the video.
3. Then quickly click again to pause the video.
4. Wait for the video controls to show that the video is buffering.
5. Then click again to play the video.

RESULT:
The player buffers the entire video, but the video never plays, even if I seek around or toggle the HD stream on/off.

Comment 14

[Ralph Giles (:rillian)]

Chris, can you do a build w/o jwwang's change and see if that fixes the issue?

Comment 15

[Chris Peterson [:cpeterson]]

I was unable to cleanly back out jwwang's change for bug 1223599 due to some merge conflicts. However, as noted in comment 0, I bisected this regression to a mozilla-inbound build whose pushlog has exactly one commit: bug 1223599.

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ada1afb12a16333d26974328d0f340712f354bf2&tochange=7fbfb74b3dd32634e4cdc314ab9f48eaeaeada6a