pipeline Gstremer video streaming with delay - gstreamer

Question

Is it possible to give some delay in between before sending demuxed, h264-decoded output to autovideosink in gstreamer pipeline. If so can anybody post sample pipeline to do that.
The pipeline which I used is
udpsrc port=5000 ! mpegtsdemux name=demux ! queue ! ffdec_h264 ! ffmpegcolorspace ! autovideosink demux. ! queue ! ffdec_mp3 ! audioconvert ! alsasink demux
In this case once the stream is received at upd-port 5000 it will immediately start playing after demuxing-queuing-decoding. Is there any-possibilty of delay say 60sec befoe sending it to autovideosink where it is actually played.Is there any Gstreamer plugin/element to do that.

Answer 1

You might want look at queue's parameters (run gst-inspect queue):
max-size-buffers : Max. number of buffers in the queue (0=disable)
flags: lesbar, schreibbar
Unsigned Integer. Range: 0 - 4294967295 Default: 200
max-size-bytes : Max. amount of data in the queue (bytes, 0=disable)
flags: lesbar, schreibbar
Unsigned Integer. Range: 0 - 4294967295 Default: 10485760
max-size-time : Max. amount of data in the queue (in ns, 0=disable)
flags: lesbar, schreibbar
Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 1000000000
min-threshold-buffers: Min. number of buffers in the queue to allow reading (0=disable)
flags: lesbar, schreibbar
Unsigned Integer. Range: 0 - 4294967295 Default: 0
min-threshold-bytes : Min. amount of data in the queue to allow reading (bytes, 0=disable)
flags: lesbar, schreibbar
Unsigned Integer. Range: 0 - 4294967295 Default: 0
min-threshold-time : Min. amount of data in the queue to allow reading (in ns, 0=disable)
flags: lesbar, schreibbar
Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 0
By setting min-threshold-time you can delay the output by n nanoseconds.
I've just tried that out with my webcam and it worked (60secs delay):
gst-launch v4l2src ! queue max-size-buffers=0 max-size-time=0 max-size-bytes=0 min-threshold-time=60000000000 ! autovideosink
Note that I've set the max-size-* parameters to 0 because if the queue fills up before the threshold is met, you won't get data out the queue.
And keep in mind that queueing a decoded video stream might result in huge memory usage.
With your encoded udpsrc I'd recommend delaying the encoded h264 stream. You might need to set the threshold in bytes instead of nanoseconds (I don't think the queue knows enough about the encoded data to make a guess on the bitrate).

Answer 2

My solution was to add the delay to the autoaudiosink. A nifty feature, cryptically called ts-offset:
$ gst-launch-1.0 souphttpsrc location=http://server:10000/ ! queue \
max-size-bytes=1000000000 max-size-buffers=0 max-size-time=0 ! \
decodebin ! autoaudiosink ts-offset=500000000
min-threshold-* weren't working for me.
The delay works. Disabling synchronisation also worked:
$ gst-launch-1.0 souphttpsrc location=http://server:10000/ ! \
decodebin ! autoaudiosink sync=false
For music, like what I am using it for, the synchronisation didn't really matter, except that it's nice having the next song come on sooner than later when changing tracks. So I still preferred the half second delay.
When disabling synchronisation, typically, the stream slowly goes out of sync. For a live stream, whose data is being generated in real time, the stream synchronisation can be maintained by asking the queue to dump extra data:
gst-launch-1.0 souphttpsrc location=http://server:10000/ ! \
queue max-size-bytes=65536 max-size-buffers=0 max-size-time=0 \
leaky=downstream ! decodebin ! autoaudiosink sync=false
This keeps the stream synchronised to within 64KiB of the time the data was first made available on the server. This ended up being my preferred solution, since I was streaming data that was being generated in real time by the sound card of a computer on the same wifi network. This is for live streams only. This will not work if the stream's data has been predetermined, in which case the entire stream will be downloaded as quickly as possible, resulting in the whole thing being played more or less in fast forward.