swtching streams within webrtcbin

[Alexander Yanin]

I think both options can be used, each has its own advantages. In my case
number of audio tracks greatly varies (from 1 to ~40 or more), so option 2
sounds more appropriate because of narrower bandwidth and lower cpu usage
(no coding and packing of unnecessary audio tracks).
So, is option 2 applicable at the moment or it needs webrtcbin updating?

2018-03-27 15:12 GMT+03:00 Matthew Waters <ystreet00 at gmail.com>:

> Hi!
>
> Two options:
>
> 1. Send all the media all the time and switch client side.
> 2. Selectively send the required stream based on notifications from the
> client.
>
> The ideal choice depends on the bandwidth and switching latency
> requirements you need with 1 using more bandwidth and switching is
> ~instantaneous. 2 uses less bandwidth but switching requires at least a
> roundtrip through the signaling.
>
> 2 requires adding some extra signaling for notifying about stream switches
> but that is relatively to easy add into the existing webrtc signaling
> channel.  The current snag is that webrtcbin still has a very much
> work-in-progress renegotiation handling which means that 1 is really the
> easiest option at the moment.  I would very much like to get 2 working with
> webrtcbin though.
>
> Cheers
> -Matt
>
>
> On 27/03/18 19:23, Alexander Yanin wrote:
>
> Hi!
> I was glad to know that gstreamer now has its own webrtc implementation.
>
> My purpose is to use webrtcbin for live media streaming to multiple
> clients (browsers) without receiving any media from them. The streamed
> media consists of one video stream and several audio streams. My purpose is
> to have a possibility for a client to switch from one audio track to
> another. For simplicity, other clients will also receive the same selected
> audio track.
>
> How this can be achieved? What is the most correct way to do that?
>
> Cheers,
> Alex
>
>
> _______________________________________________
> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20180327/5c617ae4/attachment-0001.html>