pipeline Gstremer video streaming with delay

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

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.