RTP Forward to GStreamer has corrupted frames
matteo.valdina at gmail.com
Wed Sep 26 18:58:31 UTC 2018
Could you try to add a queue after the decoder?
My suspect it is a slow down in the pipeline that could lead to some data
be discarded by the decoder.
On Wed, Sep 26, 2018, 10:44 Nicolas <nicolas at ubble.ai> wrote:
> Hi all,
> We have started playing with GStreamer recently, and it works very nicely !
> Our use case is video only. We stream in webRTC from browsers to Janus
> Gateway, which itself forwards an RTP stream to our backend (using Janus
> Video Room plugin). Janus is also recording the video in a file.
> Browser ---------> Janus -----------> Gstreamer
> WebRTC RTP
> In our backend, the RTP stream is decoded with Gstreamer, to be analyzed
> with computer vision algorithms.
> The whole pipeline works nicely, but we observed a weird behavior. We
> compared the frames decoded by GStreamer, and the video recorded by Janus.
> We realized that frames read by GStreamer are sometimes corrupted, while
> video file never have issues. This corruption starts low, and amplifies
> until frames get totally unreadable. After a few seconds, the stream comes
> back to normal. (Attached some examples)
> The Gstreamer pipeline we use, that provided the best results so far is:
> ```udpsrc port=17004 ! application/x-rtp,clock-rate=90000,payload=96 !
> ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! app```
> We've tried using a rtpjitterbuffer, which did not solve the issue.
> I'd be glad to hear suggestions on where to look at next, and even experts
> that could help pipoint the issue !
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel