1189869 - SoundCloud is not able to play the track

Status: RESOLVED WORKSFORME

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

Description

[yugiohjcj]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0
Build ID: 20150731145413

Steps to reproduce:

I go to SoundCloud and I play a track


Actual results:

The track has not be played


Expected results:

The track should be played

Comment 1

[yugiohjcj]

No problem on Firefox 31.0, the problem happens on Firefox 39.0.

Comment 2

[yugiohjcj]

Firefox 38.0 has the same problem but Firefox 37.0 has not this problem (tested with the official binaries on Slackware 14.1).
So, it is probably something new in Firefox 38.0 that could be the cause of this bug.

Comment 3

[Loic]

Could you test with the build compiled by Mozilla, please.
https://www.mozilla.org/en-US/firefox/all/

Comment 4

[yugiohjcj]

Sorry, when I say "tested with the official binaries on Slackware 14.1" I mean the official binaries provided by Mozilla.
To be exact these binaries:
- http://ftp.mozilla.org/pub/firefox/releases/37.0/linux-i686/en-US/firefox-37.0.tar.bz2
- http://ftp.mozilla.org/pub/firefox/releases/38.0/linux-i686/en-US/firefox-38.0.tar.bz2

Comment 5

[Loic]

Ok, so maybe there is a regression in Firefox 38.

Could you install the tool mozregression to find a regression range, please.
See http://mozilla.github.io/mozregression/ for details.
Just run "mozregression --good-release 37" and copy the pushlog you get in the console output (no need to bisect).

If mozreg doesn't work on your distro, you can download the nightly builds manually from the Mozilla FTP (I believe you know it), in each mozilla-central directory, there is a build for Linux.
FF37 nightlies started in January 2015: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2015/01/

Comment 6

[yugiohjcj]

I don't understand your instructions.
What tarball I need to download to get the "mozregression" tool please?

Comment 7

[Loic]

All is explained here: http://mozilla.github.io/mozregression/install.html
See the section about the command line tool, you need to install  python 2.7 if it's not already the case (sudo apt-get install python-pip) then you install mozreg (sudo pip install -U mozregression).

Comment 8

[yugiohjcj]

OK, done!
Here is the pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6441783352b4&tochange=8c716f35d9ec

Comment 9

[Nickolay_Ponomarev]

Luckily that window has the only one cset. Unluckily the bug it references is hidden from the public.

8c716f35d9ec	Ralph Giles — Bug 1080995 - Don't use the h264parser gstreamer element. r=kinetik

Comment 10

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

The gstreamer element h264parse has been blacklisted due to the security bug below. The blacklisting has been reversed in distro builds that include this fix.

gst-plugins-bad0.10 (0.10.22.3-2ubuntu2.3) precise-security; urgency=medium

  * SECURITY UPDATE: denial of service and possible code execution via
    incorrect nal size
    - debian/patches/CVE-2015-0797.patch: check nal size in
      gst/videoparsers/gsth264parse.c.
    - CVE-2015-0797
 -- Marc Deslauriers <email address hidden>   Wed, 15 Apr 2015 11:44:46 -0400

Comment 11

[yugiohjcj]

I confirm that this is the blacklisting of the gstreamer element h264parse that makes Firefox 39.0 not able to play the track on SoundCloud.
Indeed, I have patched the Firefox 39.0 source code then it is now able to play the track.
This patch just removes the blacklisting.
I think it is not safe to apply my patch (from a security point of view) but as I need to play tracks on SoundCloud, that is a workaround that I accept to use.
If you have better suggestions, please give me them.

Comment 12

[yugiohjcj]

Attachment: mozilla-firefox-39.0.patch: A patch for Firefox 39.0 that modifies the blacklisting in order to be able to play tracks on SoundCloud (it is not safe to apply this patch)

I attach the patch I have applied to Firefox 39.0.

Comment 13

[David Ross]

Also experiencing this in 40 Build ID 20150807085045

Comment 14

[Jonas Thiem]

Because I seem to have a fixed gstreamer version but Firefox still seems to apply this blacklist, I filed a bug that this should not be happening (in general): https://bugzilla.mozilla.org/show_bug.cgi?id=1194875 It would really be nice if multimedia components could either be blocked in a way that actually checks whether the version is known to be vulnerable, or at least allows an override _without patching and rebuilding the entire browser_.

Comment 15

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

(In reply to Jonas Thiem from comment #14)
> Because I seem to have a fixed gstreamer version but Firefox still seems to
> apply this blacklist, I filed a bug that this should not be happening (in
> general): https://bugzilla.mozilla.org/show_bug.cgi?id=1194875 It would
> really be nice if multimedia components could either be blocked in a way
> that actually checks whether the version is known to be vulnerable, or at
> least allows an override _without patching and rebuilding the entire
> browser_.

Use your distro version of Firefox.

Comment 17

[Jonas Thiem]

So your official stance on this that I cannot use the official firefox version?

I prefer nightly for a couple of reasons, mainly because stable without electrolysis is unbearably sluggish.

I can use chromium instead to get a snappy browser after all, but I would prefer not to. Isn't there a better way that doesn't screw over people with the official build instead of the distro versions?

Comment 18

[Ralph Giles (:rillian)]

This sounds like a duplicate of bug 1177363, where we applied a change enquivalent to the second hunk of your patch. This is in current nightly builds and would become part of Firefox 42 on release.

It would be great if you could check whether that change resolves your issue with soundcloud.

Comment 19

[Ralph Giles (:rillian)]

(In reply to Jonas Thiem from comment #14)
> It would
> really be nice if multimedia components could either be blocked in a way
> that actually checks whether the version is known to be vulnerable,

Yes. I tried to do a version-specific block, but had re-entrancy problems checking the version inside the autoplug filter and couldn't get it to work.

> or at
> least allows an override _without patching and rebuilding the entire
> browser_.

There's an undocumented pref "media.gstreamer.enable-blacklist" which, when set to false, bypasses the check for vulnerable gstreamer elements. It is of course not safe to set this either since it disables all checks, not just the h264parse issue which is patched in some gstreamer distros. https://dxr.mozilla.org/mozilla-central/source/dom/media/gstreamer/GStreamerFormatHelper.cpp#217

Comment 20

[supaiku]

Still not working with latest Nightly.

Comment 21

[Jean-Yves Avenard [:jya]]

gstreamer is going in bug 1234092