RTP Forward to GStreamer has corrupted frames

[Matteo Valdina]

I suggest enabling the log. My first suspect, it is something related to
the SSRC/TS  of the new stream. You can give a try with the rtpbin that
contains the jitter.

On Wed, Oct 3, 2018 at 7:29 AM Nicolas <nicolas at ubble.ai> wrote:

> Hi Matteo, Arjen and all,
>
> We've made a series of tests on the GStreamer pipeline, as well as running
> GStreamer in the same machine as Janus.
>
> We ended up with a setup that seems to yield a good quality for our use
> case:
>  - adding a rtpjitterbuffer as suggested (without playing with latency for
> now)
>  - adding threads to the vp8dec element (threads=4)
>  - running GStreamer natively instead of within Python
>
> This uncovered another issue... we're streaming 3 successive sequences. In
> between each sequence, the publisher stops the stream, then relaunch a new
> one, forwarded in a similar way to GStreamer. GStreamer is unchanged.
>
> This works fine with all setups we tested *except* when we use a
> Jitterbuffer. When a Jitterbuffer is used, nothing is received for the
> second scene.
>
> Do you have any idea where the issue might be coming from?
>
> Thanks,
> nicolas
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>


-- 
“There are two ways of constructing a software design: One way is to make
it so simple that there are obviously no deficiencies, and the other way is
to make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.”
- Tony Hoare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20181003/63a64ef1/attachment-0001.html>