RTP Source + multiple webrtcbin's - no on-negotiation-needed?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

RTP Source + multiple webrtcbin's - no on-negotiation-needed?

Dominik Röttsches
Hi Matthew and others,

I would like to implement a webrtc video server, where a permanent RTP packet source produces the video packets ready for delivery. Then multiple webrtcbin’s get added to the pipeline which handle the individual connections to peers and send them the video feed from the RTP packet source.

So I prepare a pipeline similar to this:

videotestsrc ! video/x-raw,width=640,height=480,framerate=15/1 ! clockoverlay halignment=right valignment=bottom shaded-background=true font-desc="monospace, 24" ! queue max-size-bytes=2500000 ! videoconvert ! vtenc_h264 ! video/x-h264,profile=baseline !  h264parse ! rtph264pay ! queue max-size-bytes=2500000 ! application/x-rtp,media=video,encoding-name=H264,payload=97 ! tee name=rtp_src ! queue ! fakesink

And set it to playing. It starts producing RTP packets.

For each new WebRTC connection, I now would like to add webrtcbins that connect to the rtp_src tee, hooked up with a queue, such as
“queue ! webrtcbin” (connected to tee name=rtp_src)”
So I make the element, link the queue to tee, and the webrtcbin to the queue.

The problem is, if the pipeline is already playing, I do not receive an “on-negotiation-needed” signal for the new webrtcbin.

Do I need this signal? Or can I just emit a “create-offer” signal on the new one?

I observed that if I set the pipeline state to NULL, then PLAYING, the newly added element sends the “on-negotiation-needed”. But doing it this way is not practical for multiple elements, as the original connections break when stopping the pipeline.

Any suggestions? Can I somehow tell the new element to trigger the on-negotiation-needed signal?

Thank you!

Dominik

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: RTP Source + multiple webrtcbin's - no on-negotiation-needed?

Philippe Normand
Hi Dominik,

> On 8 Dec 2018, at 13:08, Dominik Röttsches <[hidden email]> wrote:
>
> Hi Matthew and others,
>
> I would like to implement a webrtc video server, where a permanent RTP packet source produces the video packets ready for delivery. Then multiple webrtcbin’s get added to the pipeline which handle the individual connections to peers and send them the video feed from the RTP packet source.
>
> So I prepare a pipeline similar to this:
>
> videotestsrc ! video/x-raw,width=640,height=480,framerate=15/1 ! clockoverlay halignment=right valignment=bottom shaded-background=true font-desc="monospace, 24" ! queue max-size-bytes=2500000 ! videoconvert ! vtenc_h264 ! video/x-h264,profile=baseline !  h264parse ! rtph264pay ! queue max-size-bytes=2500000 ! application/x-rtp,media=video,encoding-name=H264,payload=97 ! tee name=rtp_src ! queue ! fakesink
>
> And set it to playing. It starts producing RTP packets.
>
> For each new WebRTC connection, I now would like to add webrtcbins that connect to the rtp_src tee, hooked up with a queue, such as
> “queue ! webrtcbin” (connected to tee name=rtp_src)”
> So I make the element, link the queue to tee, and the webrtcbin to the queue.
>

Just asking to make sure, do you synchronise the state of the 2 elements with the pipeline state after adding them and linking to the tee?

Philippe

> The problem is, if the pipeline is already playing, I do not receive an “on-negotiation-needed” signal for the new webrtcbin.
>
> Do I need this signal? Or can I just emit a “create-offer” signal on the new one?
>
> I observed that if I set the pipeline state to NULL, then PLAYING, the newly added element sends the “on-negotiation-needed”. But doing it this way is not practical for multiple elements, as the original connections break when stopping the pipeline.
>
> Any suggestions? Can I somehow tell the new element to trigger the on-negotiation-needed signal?
>
> Thank you!
>
> Dominik
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: RTP Source + multiple webrtcbin's - no on-negotiation-needed?

Dominik Röttsches
Hi Philippe,

On Dec 8, 2018 18:30, Philippe Normand <[hidden email]> wrote:

> For each new WebRTC connection, I now would like to add webrtcbins that connect to the rtp_src tee, hooked up with a queue, such as
> “queue ! webrtcbin” (connected to tee name=rtp_src)”
> So I make the element, link the queue to tee, and the webrtcbin to the queue.


Just asking to make sure, do you synchronise the state of the 2 elements with the pipeline state after adding them and linking to the tee?


That is a good hint. So far I did not do anything to the added elements' state - since I was assuming they would somehow take their state from the rest of the pipeline - but I guess that assumption is wrong?

What would be the best way to sync them? 

Thanks for the suggestion,

Dominik

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: RTP Source + multiple webrtcbin's - no on-negotiation-needed?

Sebastian Dröge-3
On Sat, 2018-12-08 at 22:04 +0200, Dominik Röttsches wrote:
>
> That is a good hint. So far I did not do anything to the added
> elements' state - since I was assuming they would somehow take their
> state from the rest of the pipeline - but I guess that assumption is
> wrong?
>
> What would be the best way to sync them?

The easiest option would be gst_element_sync_state_with_parent() after
adding the elements to their bin.

--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (981 bytes) Download Attachment