1048255 - Video on air.mozilla.org is stuttering / hanging when switching into full screen mode

Status: VERIFIED FIXED

(Webtools Graveyard :: Air Mozilla, defect, P3)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140804004002 CSet: 352420f664bf

I can first see this issue with an Aurora 33.0a2 build, but not with the latest beta which is at 32.0. So it looks like a regression in Firefox 33.0.

Steps:
1. Open a video on air.mozilla.org like https://air.mozilla.org/mozilla-weekly-project-meeting-20140728/
2. Start playing the video
3. Click on the fullscreen button

After step 3 the output starts to stutter and hangs continuously. Video and audio are drifting apart. Also exiting full screen mode afterward doesn't help. The stuttering keeps the same for a while. After a couple of seconds video will work smoothly again, but the lag between audio and video persists, and forces you to reload the page.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Actually this also happens on OS X. So expanding the platform settings.

Comment 2

[Andreea Matei [:AndreeaMatei]]

I can see that too on Linux with latest aurora.

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Video is an key component of Firefox. Tracking.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I started the regression tests for nightlies and continued with inbound builds. Finally mozregression found it!

Ensuring we have enough metadata to get a pushlog...
Last good revision: 37f08ddaea48 (2014-06-18)
First bad revision: f78e532e8a10 (2014-06-19)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=37f08ddaea48&tochange=f78e532e8a10

No more inbounds to bisect
Last good revision: 9d86b9442f0b
First bad revision: 5519fd827576
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9d86b9442f0b&tochange=5519fd827576

There is only a single bug 979104 referenced in this pushlog. Chris, can you have a look at this?

Comment 5

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

How odd. For some reason air.mo is doing a seek when you enter fullscreen mode, which is causing the pause.

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Chris, any chance you could address that before 33 move to beta? Thanks

Comment 7

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

(In reply to Henrik Skupin (:whimboo) [away 08/16 - 08/23] from comment #4)
> Last good revision: 9d86b9442f0b

I still see this issue with this changeset. It appears to happen more frequently after this changeset, probably due to the decoding being more asynchronous after this changeset.

The problem is that the page (vid.ly?) is setting the currentTime to the currentTime when it opens fullscreen. This causes us to seek if the current playback position inside the video decoder has gotten ahead of the value visible on the main/JS thread, which causes the stutter.

Comment 8

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

I see the stutter upon going fullscreen in Chrome too. This just seems like non-optimal behaviour on the part of the web site. vid.ly *should not* seek when it enters fullscreen, this is what is causing the problem, not any change on our side.

I don't see the output start to stutter and hang once going fullscreen, but I suspect that you're seeing poor network performance causing us to enter buffering state. Can you try enabling NSPR_LOG_MODULES=MediaDecoder:5,nsMediaElement:5 and checking whether you see lines like "Decoder=1b111110 Changed state from DECODING to BUFFERING, decoded for 0.156s" when the stuttering occurs?

This should be an evangelism or air.mozilla bug; the vid.ly code needs to not seek when they enter fullscreen.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Sorry about the noise, I had to update the tracking flags to remove it from our radar

Comment 10

[Richard A Milewski[:richard]]

Opened ticket #13104 with vid.ly on this issue.

Comment 11

[Richard A Milewski[:richard]]

Response from Vid.ly support:

Richard,

I just tested on MacOS 10.8 and Windows 8.1 using both Firefox and Chrome in both SD and HD mode. Looks fine to me. They buffer normally and begin playing after a second or two. I don't see any stuttering.

Tested your link at:

https://air.mozilla.org/mozilla-weekly-project-meeting-20140728/

And one of mine:

http://vid.ly/washday

We are having some other problems with Android 4.2, and our devs are already testing a fix for that on our QA staging cloud. If this stutter is on Android 4.2, please let me know and I will add a note to that ticket.

If not Android 4.2:

1. What device and and OS version are you working on?

2. Which player version are you using (default, JW Player, or FlowPlayer)

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Btw. this is still totally reproducing for me with latest Aurora build on Linux. So nothing has changed.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Maybe an update here for the steps:

1. Open the URL and start the Video
2. Click fullscreen button
3. Let the video play for a little bit (I can already see that the sound is behind)
4. Click fullscreen button to reduce the size
5. Click fullscreen button again

With step 5 the video is totally stuttering with the video output.

Comment 14

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

(In reply to Richard A Milewski[:richard] from comment #11)
> Response from Vid.ly support:

It's not clear to me that they understand and tested the problem we're reporting. The problem is that when an air.mo video enters fullscreen while playing back, their site JavaScript needlessly seeks the video, and this is what causes the stutter.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Chris, do we have any update from their support? It's really getting annoying meanwhile given that I cannot watch any video on air.m.o with Firefox those days.

Comment 16

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

Henrik, I have had no contacts with Vid.ly, you should ask Richard A Milewski. AFAICT, they couldn't reproduce a problem, and they didn't fix their JS to stop it doing an unnecssary seek.

Comment 17

[Richard A Milewski[:richard]]

I retested with the steps in Comment 13 and WAS able to reproduce the problem.  I'll re-open a ticket with Vid.ly and see if we can get to the bottom of the problem, especially when viewing the HD version.

Video stalls when viewing HD can be a problem with total available bandwidth at the viewer end, but I was able to reproduce the problem on a wired connection in a Mozilla office, so I doubt that's the case here.

I'll report back what I hear from Vid.ly.

Comment 18

[Richard A Milewski[:richard]]

Appears to be fixed now.  Please reopen if this is still a problem.

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Works great. Thanks for the update and assistance in getting this fixed Richard!