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 696501 - avdec: better multi-threaded decoding performance for live pipelines where downstream does not sync to clock
avdec: better multi-threaded decoding performance for live pipelines where do...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 663617 697690 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-03-24 17:40 UTC by Tim-Philipp Müller
Modified: 2018-11-03 12:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim-Philipp Müller 2013-03-24 17:40:36 UTC
Currently we always use FF_THREAD_SLICE mode for multithreaded H.264 decoding.

This mode requires encoder support, so multiple threads will only be used if the H.264 video is encoded in a suitable way (i.e. with multiple slices per frame). This is not necessarily the case, and where this is not the case decoding will be done in a single thread only, hampering performance.

We should use FF_THREAD_SLICE only for live pipelines where latency is important, and use FF_THREAD_FRAME for decoding scenarios where latency does not matter, to make sure we actually use multiple threads for decoding if possible.
Comment 1 Sebastian Dröge (slomo) 2013-03-25 07:54:26 UTC
See also https://bugs.freedesktop.org/show_bug.cgi?id=56206
Comment 2 Olivier Crête 2013-03-25 21:34:54 UTC
As I noted on the SDK bug, we should add some way to communicate application-specific latency requirements throughout the pipeline, allowing anything but zero-latency decoders for live RTP pipelines also means solving the variable framerate problem!
Comment 3 Tim-Philipp Müller 2013-03-25 21:52:53 UTC
Ok, but I don't think this bug depends in any way on the app being able to communicate latency requirements, does it?

Since we're starting from a minimal-latency-not-very-efficient scenario, simply switching to FF_THREAD_FRAME for non-live pipelines should always be acceptable, no?

Then also switching to FF_THREAD_FRAME for live pipelines where the latency requirements are > N frames with N=max-cores (or so) would be an added bonus.
Comment 4 Tim-Philipp Müller 2013-04-05 16:36:09 UTC
*** Bug 663617 has been marked as a duplicate of this bug. ***
Comment 5 Tim-Philipp Müller 2013-04-05 16:38:04 UTC
As Olivier noted on IRC a while ago, we can switch to FF_THREAD_FRAME for better performance not only if upstream is not live, but also if nothing downstream syncs to the clock (though we don't have a way to query that yet).
Comment 6 Tim-Philipp Müller 2013-04-10 08:25:36 UTC
*** Bug 697690 has been marked as a duplicate of this bug. ***
Comment 7 Sebastian Dröge (slomo) 2013-08-20 14:02:57 UTC
Isn't that fixed now with http://cgit.freedesktop.org/gstreamer/gst-ffmpeg/commit/?id=2d2c9b1aac6f2fa3a1a7c8a9ed46b76cefe228c8
Comment 8 Tim-Philipp Müller 2013-08-20 14:16:23 UTC
> Isn't that fixed now with 2d2c9b1a ?

No, I think there are still some cases we're missing which could be improved, see comment 5: we can use FF_THREAD_FRAME even if upstream is live, as long as downstream does not sync to the clock.
Comment 9 GStreamer system administrator 2018-11-03 12:55:53 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-libav/issues/9.