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 758195 - vpxdec: Use more threads by default
vpxdec: Use more threads by default
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal enhancement
: 1.7.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-11-16 21:25 UTC by Nicolas Dufresne (ndufresne)
Modified: 2015-11-17 17:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
vpxsdec: Use threads on multi-core systems (3.31 KB, patch)
2015-11-16 21:26 UTC, Nicolas Dufresne (ndufresne)
none Details | Review
vpxsdec: Use threads on multi-core systems (3.24 KB, patch)
2015-11-17 00:30 UTC, Nicolas Dufresne (ndufresne)
none Details | Review
vpxdec: Use threads on multi-core systems (3.24 KB, patch)
2015-11-17 00:31 UTC, Nicolas Dufresne (ndufresne)
committed Details | Review

Description Nicolas Dufresne (ndufresne) 2015-11-16 21:25:42 UTC
We now have a thread option vpxdec though we are nearly never using it. I notice this when comparing SW decoding capabilities of Chromium against GStreamer. This is a quick attemps, but I propose adding adding an automatic mode, so we use as many threads as there is CPUs on the platform.
Comment 1 Nicolas Dufresne (ndufresne) 2015-11-16 21:26:13 UTC
Created attachment 315708 [details] [review]
vpxsdec: Use threads on multi-core systems

This adds an automatic mode to the threads property of vpxdec in order to
use as many threads as there is CPU on the platform. This bring back
GStreamer VPX decoding performance closer to what is achieve by other
players, including Chromium.
Comment 2 Tim-Philipp Müller 2015-11-16 21:42:46 UTC
Seems like a good idea. I'd just say "(0 = automatic)" in the property description, then we are free to tweak the details later if ever needed.

We might also want to compare how the libav vp8/vp9 decoder fare performance-wise. They're currently on marginal rank, but perhaps their rank should be increased.
Comment 3 Nicolas Dufresne (ndufresne) 2015-11-17 00:22:02 UTC
Agreeds about the documentation. You seem right about the performance. I did a quick experiment, nothing very scientific. I decoded the same 720p VP9 stream with libvpx and ffmpeg, and got:

Libvpx: 0:00:44.166014779
FFMPEG: 0:00:25.987353323
Comment 4 Nicolas Dufresne (ndufresne) 2015-11-17 00:26:37 UTC
Ok, forgot to look at the result, the FFMPEG output is not visually correct.
Comment 5 Nicolas Dufresne (ndufresne) 2015-11-17 00:30:29 UTC
Created attachment 315722 [details] [review]
vpxsdec: Use threads on multi-core systems

This adds an automatic mode to the threads property of vpxdec in order to
use as many threads as there is CPU on the platform. This bring back
GStreamer VPX decoding performance closer to what is achieve by other
players, including Chromium.
Comment 6 Nicolas Dufresne (ndufresne) 2015-11-17 00:31:37 UTC
Created attachment 315723 [details] [review]
vpxdec: Use threads on multi-core systems

This adds an automatic mode to the threads property of vpxdec in order to
use as many threads as there is CPU on the platform. This brings back
GStreamer VPX decoding performance closer to what is achieved by other
players, including Chromium.
Comment 7 Nicolas Dufresne (ndufresne) 2015-11-17 17:38:16 UTC
Wrong push, commenting manually ;-P

commit b848c1b6ffd1e508228820a013f94fb445e4777f
Author: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Date:   Mon Nov 16 16:23:43 2015 -0500

    vpxdec: Use threads on multi-core systems
    
    This adds an automatic mode to the threads property of vpxdec in order to
    use as many threads as there is CPU on the platform. This brings back
    GStreamer VPX decoding performance closer to what is achieved by other
    players, including Chromium.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=758195