After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 731886 - YouTube HTML5 HD videos stall in Firefox 30.0 when gstreamer-vaapi is installed
YouTube HTML5 HD videos stall in Firefox 30.0 when gstreamer-vaapi is installed
Status: RESOLVED FIXED
Product: gstreamer-vaapi
Classification: Other
Component: general
0.5.8
Other Linux
: Normal normal
: ---
Assigned To: gstreamer-vaapi maintainer(s)
gstreamer-vaapi maintainer(s)
Depends on:
Blocks: 720305
 
 
Reported: 2014-06-18 21:12 UTC by Simon Farnsworth
Modified: 2015-02-14 13:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Log collected as described in the initial report (13.07 KB, text/plain)
2014-06-18 21:12 UTC, Simon Farnsworth
Details

Description Simon Farnsworth 2014-06-18 21:12:25 UTC
This is a clone of https://bugzilla.redhat.com/show_bug.cgi?id=1109465

I run Firefox from the Fedora 20 package with:

$ GST_DEBUG=*:2,vaapi*:4 firefox

I have gstreamer1-vaapi from Fedora, version 0.5.8-3 installed; this is 0.5.8 with the patch from https://bugzilla.gnome.org/show_bug.cgi?id=723834 applied.

If I leave gstreamer1-vaapi in place, I see the video stall for at least 1 second at a time between output frames; audio continues, suggesting that Firefox's GStreamer pipeline is still running. Removing gstreamer1-vaapi fixes this, at the expense of software-only decode.

I'm going to attach the log I took with GST_DEBUG=*:2,vaapi*:4 firefox, in case there's anything obvious. I'm on IVB (i5-3210M); the original reporter is on HSW (i5-4570). libva and libva-intel-driver are the latest versions in Fedora 20 and RPMrFusion for Fedora 20:

$ rpm -q libva libva-intel-driver gstreamer1-vaapi
libva-1.2.1-2.fc20.x86_64
libva-intel-driver-1.2.2-2.fc20.x86_64
gstreamer1-vaapi-0.5.8-3.fc20.x86_64

I'm happy to run tests if there's anything more you need.
Comment 1 Simon Farnsworth 2014-06-18 21:12:59 UTC
Created attachment 278717 [details]
Log collected as described in the initial report
Comment 2 Simon Farnsworth 2014-06-18 21:14:13 UTC
Forgot to mention; this happens with multiple videos, but http://www.youtube.com/watch?v=6v2L2UGZJAM is a good example. You will need to set the video player manually to 720p or above; lower resolutions do not show the issue.
Comment 3 Gwenole Beauchesne 2014-06-18 21:44:42 UTC
Could you please try with git master branch? I had applied a patch (7105322) that could help thread safety during initialization. Thanks.

BTW, what does the g_slice_set_config error relate to? Would it be possible to G_DEBUG=fatal_criticals and bt from that?
Comment 4 Simon Farnsworth 2014-06-19 20:36:43 UTC
(In reply to comment #3)
> Could you please try with git master branch? I had applied a patch (7105322)
> that could help thread safety during initialization. Thanks.
> 
git master doesn't help - same problems with git master as of commit 1a2c06a81cb7d78609b99b5906f528070da9cad6


> BTW, what does the g_slice_set_config error relate to? Would it be possible to
> G_DEBUG=fatal_criticals and bt from that?

GNU gdb (GDB) Fedora 7.7.1-13.fc20
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib64/firefox/firefox...Reading symbols from /usr/lib/debug/usr/lib64/firefox/firefox.debug...done.
done.
(gdb) run
Starting program: /usr/lib64/firefox/firefox --debugger=gdb --debugger-args=-nx
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff4608700 (LWP 1177)]
[Thread 0x7ffff4608700 (LWP 1177) exited]

(process:1172): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000003b164504e9 in g_logv (log_domain=0x3b164b2f4e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffc390) at gmessages.c:989
989                     G_BREAKPOINT ();
(gdb) t a a bt

Thread 1 (Thread 0x7ffff7fcd780 (LWP 1172))

  • #0 g_logv
    at gmessages.c line 989
  • #1 g_log
    at gmessages.c line 1025
  • #2 XREMain::XRE_main
    at /usr/src/debug/firefox-30.0/mozilla-release/toolkit/xre/nsAppRunner.cpp line 4052
  • #3 XRE_main
    at /usr/src/debug/firefox-30.0/mozilla-release/toolkit/xre/nsAppRunner.cpp line 4291
  • #4 do_main
    at /usr/src/debug/firefox-30.0/mozilla-release/browser/app/nsBrowserApp.cpp line 282
  • #5 main
    at /usr/src/debug/firefox-30.0/mozilla-release/browser/app/nsBrowserApp.cpp line 643

Looks like it's in Firefox, not in GStreamer.
Comment 5 Gwenole Beauchesne 2014-06-20 05:12:27 UTC
OK, I will look into it. What is weird to me is that firefox exposes I420 caps only, according to the original GStreamer patch. However, gst-vaapi does not hour that, so it would expose its own buffer; or fail to negotiate (example from a custom pipeline vaapidecode ! xvimagesink).

Another reporter mentioned peformance issues too, presuming gst-vaapi worked for him. That probably was with gstreamer 0.10 then. I will look into that one too
Comment 6 Gwenole Beauchesne 2014-07-22 17:35:20 UTC
I have not tried yet, but I believe my fix to bug #733243 should help Firefox 30 too. Another patch is needed to address the "XXX" comment, i.e. handle non-I420 formats.

At least, on Intel hardware, vaapidecode ! xvimagesink works and performance is not too bad for 1080p videos (< 6% CPU usage on quick testing). Things could be further improved by 0.5.10 though.
Comment 7 Gwenole Beauchesne 2014-07-23 09:54:19 UTC
(In reply to comment #6)
> I have not tried yet, but I believe my fix to bug #733243 should help Firefox
> 30 too. Another patch is needed to address the "XXX" comment, i.e. handle
> non-I420 formats.

Correction: no, it doesn't help. Proper patches are needed at the Firefox level, but I will try to make things not too bad otherwise.

Though, another major issue in Firefox is that it doesn't care of any of the stride information, and this uses its own assumptions and just copy over the whole image, instead of on a per-plane basis.
Comment 8 Gwenole Beauchesne 2014-07-23 17:23:22 UTC
Please test the git master branch. Performance is not there yet, because of additional round-trips, but I presume this original issue is fixed.
Comment 9 Gwenole Beauchesne 2014-07-23 22:22:18 UTC
commit f2ce28e4b78afc37da0771bda3830eaa02adef85
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Wed Jul 23 23:49:53 2014 +0200

    vaapivideomemory: minor code clean-ups.
    
    Fix error messages introduced in the previous commit for the _map()
    imaplementation. Also use the new get_image_data() helper function
    to determine the base pixels data buffer from a GstVaapiImage when
    updating the video info structure from it.

commit 9cad85a93649b1b6da6084b85f807139e84a41a4
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Wed Jul 23 18:54:13 2014 +0200

    vaapivideomemory: add support for raw pixels mappings.
    
    Allow raw pixels of the whole frame to be mapped read-only. i.e. in
    cases where the buffer pool is allocated without VideoMeta API, thus
    individual planes cannot be mapped.
    
    This is initial support for Firefox >= 30.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=731886