appsrc video RTP timestamp issue
tim at centricular.com
Fri Nov 13 19:37:53 UTC 2020
On Fri, 2020-11-13 at 18:02 +0000, John Dunn wrote:
> But when I use this pipeline to send it out via RTP
> pipeline_str =
> "appsrc name=appsrc !"
> "video/x-raw, format=RGBx, width=640, height=480 !"
> "videoconvert !"
> "mfh264enc !"
> "rtph264pay pt=96 !"
> "udpsink host=127.0.0.1 port=1234 sync=true async=false";
> The following message is spewed out via GST_DEBUG
> (gstest:36956): GStreamer-CRITICAL **: 08:43:43.164:
> gst_segment_to_running_time: assertion 'segment->format == format'
> and VLC isn't able to reliably receive the stream. I have tested the
> same pipeline using videotestsrc in place of my appsrc and VLC works
> perfectly fine. My incoming frame data doesn't have any inherent time
> base so I'm just setting dst to the the current time delta from the
> start of play. I've also tried setting do-timestamp=1 on my appsrc
> but that doesn't work either and also makes the loop exit with no
> error after a second or two.
> Here's the source of my appsrc. Right now I'm trying to simulate an
> accurate 30fps source using some spinlocks but my timing isn't
> perfect - I don't know if that's a source of some of the issues. I'd
> also like to have the absolute minimum latency on sending the rtp
> packets out
That warning is probably unrelated to any of your issues. You should be
able to get rid of it by setting appsrc format=time.
There's no requirement to have appsrc timestamp the buffers or even
generate the buffers in regular intervals (although that would simulate
a live capture source best I guess). It's fine to just timestamp the
first buffer with 0 and then increase the timestamp according to the
framerate before pushing it into appsrc.
If you want the data sent out as quickly as possible you can use
appsink sync=false - but that will only work right if you throttle the
frame generation (like a capture source), if you just shove buffers
with timestamps into appsrc as quickly as you can produce them you need
appsink sync=true to make sure they will be sent out "at the right
time" in real time.
You probably don't need the async=false, that's for state changes not
related to timing, despite the (confusing) naming.
You might want to set rtph264pay config-interval=-1 to make it send out
the codec setup data in regular intervals, so new clients can sync to
I don't know if VLC can autodetect this rtp stream without being told
what the format is.
Ideally you would be serving the RTP stream via gst-rtsp-server
instead, that way the server can send setup info to the client(s) and
everything is just a tad more robust and easier to make work nicely.
More information about the gstreamer-devel