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 678086 - ffdec_h264 is not multithreaded
ffdec_h264 is not multithreaded
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-06-14 10:25 UTC by Tvrtko Ursulin
Modified: 2015-02-24 12:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tvrtko Ursulin 2012-06-14 10:25:27 UTC
Code from 0.10 GIT:
gstreamer 11c8ffb6fbd20081c49708cb41e0ec6e2ed09c27
-base 1f6056eafb6c37f4c78ed22b2796a1dcaeb51ee6
-good 50c85392cd0a8824b917790a12d92f237dbd55ce
-bad acf4463f2b9bf7a7cdbac288e50dfb41626fc8b2
-ugly 09284b9862504f73924d88ac00b2c7d08dd7a001
-ffmpeg 9761a6501b518a554fc5e52de8e9acdc4f8ced9a

Even though max_threads defaults to 0 I don't see at runtime more than one thread being used. This is as opposed to ffdec_mpeg2video which multi-threads nicely.
Comment 1 Tvrtko Ursulin 2012-08-07 13:04:16 UTC
I see at least that ffmpegdec->context->thread_count is correctly set to the number of CPUs in gstffmpegviddec.c::gst_ffmpegviddec_set_format. That should be identical behaviour to 0.10.13 release on this level. Guess I need to dig deeper to see where things are breaking. Maybe something between libav 0.7.2 and 0.8.3 which are the version used in these two gstreamer-ffmpeg releases, respectively.
Comment 2 Tvrtko Ursulin 2012-08-08 08:54:15 UTC
This line in gstffmpegviddec.c is the culprit:

   ffmpegdec->context->thread_type = FF_THREAD_SLICE;

Removing this initialisation makes threading work again.

Furthermore, in case number of threads is set to auto, libav sets it to nr_cpus + 1, while gst-ffmpeg sets it to nr_cpus. Any special reason?
Comment 3 Tvrtko Ursulin 2012-08-08 09:02:59 UTC
To expand on the second (thread_count) bit, is there a special reason gst-ffmpeg thinks it knows better than libav what the optimal number of threads is? Should it just pass through the automatic (0) setting to libav if that is what the gst-ffmpeg user has set?
Comment 4 Tvrtko Ursulin 2012-08-08 09:07:54 UTC
To answer to myself, yes there is, in libav does not set CODEC_CAP_AUTO_THREADS in ff_h264_decoder.
Comment 5 Tvrtko Ursulin 2012-08-08 09:11:50 UTC
Note that comments #3 and #4 are side notes, real issue is with thread_type.
Comment 6 Edward Hervey 2012-08-08 09:53:15 UTC
Using frame-based threading introduced several heisenbugs in the past.

In addition, it introduces a nb_thread frame latency in output.
Comment 7 Tvrtko Ursulin 2012-08-09 13:37:53 UTC
Ok, I guess I just missed the commit explaining that. I only saw the one where automatic thread selection was enabled.

On the second issue, FWIW libav devs say checking against CODEC_CAP_AUTO_THREADS is wrong and zero should just be passed in since it is an internal implementation detail.
Comment 8 Tim-Philipp Müller 2013-02-23 17:40:42 UTC
Also see bug #694230.

Could you re-test with git master by any chance? It seems to work fine for me now with master (but not 1.0, see that bug).
Comment 9 Sebastian Dröge (slomo) 2013-02-25 10:57:28 UTC
See also https://bugs.freedesktop.org/show_bug.cgi?id=56206

This should be merged and somehow tried to be auto-detected. frame-threading should only be enabled for non-live pipelines.