Bridge rooms about livekit

[davidzhao]

We do have plans to support really large rooms. Though if I'm understanding your use correctly, you should be able to join multiple rooms as a publisher, and publish your track to each room separately.

[lukasIO]

edit: misread the reply...
joining multiple rooms on the client side would however introduce a significant overhead esp. in simulcast scenarios, what i meant was a solution within the server, basically what mediasoup does with pipeToRouter https://mediasoup.org/documentation/v3/mediasoup/api/#router-pipeToRouter

[davidzhao]

pipeToRouter would only work with rooms on the same host. LiveKit is a distributed service, so we likely wouldn't introduce features that rely on the location of two different rooms.

Though, you could implement a version of bridging feature yourself by using the Go server SDK. You could do something like:

1. Connect to the source room as a hidden participant (will be supported in 0.11.1+)
2. Connect to the destination room as normal participant
3. Read tracks from source room and republish to destination

This would work well for audio and non-simulcast video tracks. With simulcast, however, only a single layer will be forwarded on.

[lukasIO]

thanks for the suggestion!

pipeToRouter would only work with rooms on the same host. LiveKit is a distributed service, so we likely wouldn't introduce features that rely on the location of two different rooms.

just fyi, it is possible to make the pipeToRouter approach work across hosts, but the signalling between hosts is just not part of mediasoup.

[davidzhao]

gotcha, that makes sense. we'll definitely take it into consideration.

[xprgv]

@davidzhao Hi. I'm trying to implement bridge (proxy) between two livekit rooms in this way:

1. Connect to the source room
2. Connect to the destination room
3. Read tracks from source room and republish to destination
   and find out that my video stream isn't stable and have regular interruptions.
   Code is here

func (proxy *LivekitProxy) proxyH264SampleTrackWithPliReport(
	incomingWebrtcTrack *webrtc.TrackRemote,
	incomingPublication *lksdk.RemoteTrackPublication,
	remoteParticipant *lksdk.RemoteParticipant,
) error {
	outcomingTrack, err := lksdk.NewLocalSampleTrack(
		webrtc.RTPCodecCapability{
			MimeType: incomingPublication.MimeType(),
		},
	)
	if err != nil {
		log.Fatal(err)
	}

	if _, err := proxy.publisherRoom.LocalParticipant.PublishTrack(outcomingTrack, &lksdk.TrackPublicationOptions{
		Name: incomingPublication.Name(),
	}); err != nil {
		log.Fatal(err)
	}

	go func() {
		sb := livekitsamplebuilder.New(
			1000,
			&codecs.H264Packet{},
			incomingWebrtcTrack.Codec().ClockRate,
			livekitsamplebuilder.WithPacketDroppedHandler(func() {
				log.Println("pli from proxy")
				remoteParticipant.WritePLI(incomingWebrtcTrack.SSRC())
			}),
		)

		for {
			rtpPacket, _, err := incomingWebrtcTrack.ReadRTP()
			if err != nil {
				log.Fatal(err)
			}

			sb.Push(rtpPacket.Clone())
			for {
				sample, _ := sb.PopWithTimestamp()
				if sample == nil {
					break
				}
				if err := outcomingTrack.WriteSample(*sample, nil); err != nil {
					log.Fatal(err)
				}
			}
		}
	}()

	return nil
}

Am I to understand that for working this way I need to implement something like rtp buffer in my application for forward error correction tasks via RTCP??

[davidzhao]

buffering is built into our Go SDK, (when you use samplebuilder, it's buffering for you). What do you mean by and find out that my video stream isn't stable and have regular interruptions ? Can you describe these in more detail?

also I see you are handling packet loss from the original publisher, but not PLI packets coming from the destination (if the forward destination dropped frames, you'll need to signal to the original room too).