GNOME Bugzilla – Bug 726381
[API] Need a way to set per pipeline/bin/element policies
Last modified: 2018-11-03 12:19:55 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
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?
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
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.
This would indeed be a great idea, maybe as a "latency target" ?
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?
-- 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.