770815 - Nightly: html5 videos are unwatchable

Status: RESOLVED DUPLICATE of bug 761274

(Core :: Audio/Video, defect)

Description

[marb]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Firefox/16.0
Build ID: 20120702030551

Steps to reproduce:

Open and play any html5 video examples:
http://leanbackplayer.com
http://videojs.com
or youtube html5 player


Actual results:

Videos play slowly or like in fast forward mode and not smooth. Sound is choppy and distorted.

Comment 1

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/16.0 Firefox/16.0

This works for me under Ubuntu 12.04 i686. Once the video has buffered, the sound and video play properly. I also tried Chrome and didn't spot any difference.

Did this previously work for you in an older Nightly or an older release? What distribution is this?

Comment 2

[marb]

I just checked and even if I let the video buffer to the end it's still a mess. The same videos play properly when using Chromium.

It was happening also in previous Nightly 15.0. It's ok on Stable Firefox 13 and on Beta 14. Distro: Arch Linux.

Comment 3

[Virgil Dicu [:virgil] [QA]]

Would you be willing to hunt down a regression range for this issue using the following tool?
http://harthur.github.com/mozregression/

If this worked with Firefox 14 and you can see it in Firefox 15, then this must have regressed in between.

By looking at https://wiki.mozilla.org/RapidRelease/Calendar then the dates to search for would be: 13.3.2012 to 24.4.2012/

Comment 4

[marb]

Last good nightly: 2012-05-22
First bad nightly: 2012-05-23

Comment 5

[Matthew Gregan [:kinetik]]

This sounds like the same issue as bug 761274.  Would you mind providing the same information I requested in that bug?  I haven't been able to reproduce this locally, so collecting this data may help narrow down the problem.  Copying from my comments in that bug:

Can you please attach the output from alsa-info.sh (found here: http://git.alsa-project.org/?p=alsa-driver.git;a=blob_plain;f=utils/alsa-info.sh) to the bug?

Can you confirm that creating and setting the boolean pref "media.use_cubeb" to false works around the problem you're seeing?

Can you try creating and setting the integer pref "media.cubeb_latency_ms" to values other than 100ms (the default) works around the issue?  Try 114, 115, 200, 500, 1000.  You only need to try the higher values if a lower value hasn't worked around the issue already.

Would you mind running PulseAudio in verbose mode, reproducing the playback problem in Firefox, and attaching the resulting PA output?  Instructions here: https://wiki.ubuntu.com/PulseAudio/Log

Thanks in advance!

Comment 6

[marb]

Yes. Creating and setting the boolean pref "media.use_cubeb" to false works around the problem.

If media.cubeb_latency_ms is >= 200 sound/video is ok.

Comment 7

[marb]

Attachment: Output from alsa-info script

Comment 8

[marb]

Attachment: pulseaudio log

Comment 9

[Matthew Gregan [:kinetik]]

Thanks!  We hadn't been able to get PA log output while reproducing this in the past as the others who saw this bug had it disappear when running PA in logging mode, so this is a big help.

(  27.937|   0.000) I: [pulseaudio] protocol-native.c: Requested tlength=100.00 ms, minreq=24.99 ms
(  27.937|   0.000) D: [pulseaudio] protocol-native.c: Early requests mode enabled, configuring sink latency to minreq.
(  27.938|   0.000) D: [pulseaudio] protocol-native.c: Requested latency=24.99 ms, Received latency=200.00 ms
(  27.938|   0.000) D: [pulseaudio] memblockq.c: memblockq requested: maxlength=4194304, tlength=211680, base=8, prebuf=26464, minreq=70560 maxrewind=0
(  27.938|   0.000) D: [pulseaudio] memblockq.c: memblockq sanitized: maxlength=4194304, tlength=211680, base=8, prebuf=26464, minreq=70560 maxrewind=0
(  27.938|   0.000) I: [pulseaudio] protocol-native.c: Final latency 800.00 ms = 200.00 ms + 2*200.00 ms + 200.00 ms

Note that we're requesting a 100ms buffer size, but we're ending up with something much larger.  This should be reflected back via the ALSA API so that we handle it, but perhaps we're not doing that correctly or there's a bug in at the alsa-pulse plugin level.  I'll dig further.

I'll mark this as a dupe of the earlier bug.