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 726381 - [API] Need a way to set per pipeline/bin/element policies
[API] Need a way to set per pipeline/bin/element policies
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-03-14 23:10 UTC by Nicola
Modified: 2018-11-03 12:19 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicola 2014-03-14 23:10:44 UTC
avdec_h264 has more latency than ffdec_h264, please test with these pipelines:

server (use 0.10 since gdppay is a bit broken in 1.0):

gst-launch-0.10 v4l2src ! x264enc tune=zerolatency ! gdppay ! tcpserversink host=127.0.0.1 port=3000 sync-method=2

client 1.0:

gst-launch-1.0 -v tcpclientsrc host=127.0.0.1 port=3000 ! gdpdepay ! fakesink sync=false silent=false

client 0.10:

gst-launch-0.10 -v tcpclientsrc host=127.0.0.1 port=3000 ! gdpdepay  ! fakesink sync=false

stop the server or kill both clients at the same time (kill -9 <pid1> <pid2>), they will print exactly the same timestamp, for example:

/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (8576 bytes, dts: 0:00:00.000000000, pts: 0:00:34.139030609, duration: 0:00:00.033333333, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7f43240069a0

/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* (fakesink0:sink) (8576 bytes, timestamp: 0:00:34.139030609, duration: 0:00:00.033333333, offset: -1, offset_end: -1, flags: 8192 ) 0x7fa300002bf0"

now change the client pipelines

client 1.0:

gst-launch-1.0 -v tcpclientsrc host=127.0.0.1 port=3000 ! gdpdepay ! avdec_h264 ! fakesink sync=false silent=false

client 0.10:

gst-launch-0.10 -v tcpclientsrc host=127.0.0.1 port=3000 ! gdpdepay ! ffdec_h264 ! fakesink sync=false

stop the server or kill the clients, you see the delay:

/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain   ******* (fakesink0:sink) (1382400 bytes, dts: 0:00:39.664793944, pts: 0:00:39.664793944, duration: 0:00:00.033333333, offset: -1, offset_end: -1, flags: 00004000 in-caps ) 0x7f8b50cf2740


/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* (fakesink0:sink) (1382400 bytes, timestamp: 0:00:39.896504848, duration: 0:00:00.033333333, offset: -1, offset_end: -1, flags: 256 delta_unit ) 0x7fcd94002dc0"

so 1.0 has about 250 milliseconds delay more than 0.10 (I observed 0.5 second too)

version used:

gstreamer 1.2.3
gstreamer 0.10.36
Comment 1 Sebastian Dröge (slomo) 2014-03-15 12:10:48 UTC
Is the latency lower if you a) set max-threads=1 on the decoder or b) set ffmpegdec->context->thread_type (look at gstavviddec.c) to 0?
Comment 2 Nicola 2014-03-15 12:36:47 UTC
max-threads=1 solve the problem

is-live=true on the source solve the problem too, 

in gstavviddec.c I see:

if (is_live)
  ffmpegdec->context->thread_type = FF_THREAD_SLICE;
else
  ffmpegdec->context->thread_type = FF_THREAD_SLICE | FF_THREAD_FRAME;

so if is_live is not setted and max-threads is not setted on my 8 core cpu probably 8 threads are used for decoding and FF_THREAD_FRAME make about 8 frame delay, this explain the 0.5 second delay that I see on stream at 15 fps
Comment 3 Sebastian Dröge (slomo) 2014-03-15 13:32:19 UTC
That makes sense, yes. We currently have no way to specify for a pipeline that it should run in "low-latency" mode vs. "high performance" mode.
Comment 4 Olivier Crête 2014-03-15 17:45:53 UTC
This would indeed be a great idea, maybe as a "latency target" ?
Comment 5 Tim-Philipp Müller 2016-08-22 16:46:50 UTC
This could now be done via some API around GstContext perhaps?

avdec_h264 could also pick a suitable mode depending on upstream and downstream live-ness (it does not do the latter yet afaik) perhaps?
Comment 6 GStreamer system administrator 2018-11-03 12:19:55 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/gstreamer/issues/51.