This message was deleted.
# cloud
s
This message was deleted.
a
I'm talking about egress id
EG_CzEGgWbRBoS7
on cloud.livekit.io.
I've tried stopping and starting the egress, but got the same behavior.
This is what the recording looks like. There should be 6 different camera's, but only 1 is shown 6 times.
a
cc @dry-elephant-14928 I think our templates assume one video
CAMERA
track per participant. For now you would need to modify the template (found at https://github.com/livekit/egress/tree/main/template-default), host it, and use the
custom_base_url
in your request
d
oh that is strange.. it's possible this is a bug with the template.. it should not be showing the same track six times.. can you share any repro steps with me? For the cameras that are publishing, what is the Track.Source?
a
Thanks @able-gigabyte-21598 for pointing out the template. Reading the code it seems all video tracks are passed into
GridLayout
without much modification. Checking in meet.livekit.io shows the same duplicate-stream behavior. I assume meet.livekit.io uses the same
GridLayout
@dry-elephant-14928 In
TrackPublicationOptions
we haven't set a
Source
, but looking at the
TrackReference[]
in the webapp I see that it has set
source: "camera"
for the video tracks. So I assume it defaults to 'camera'?
I could try to investigate the bug in the GridLayout, but if I can't figure it out I will take some time making a simple script to reproduce.
d
oh.. if you can reproduce with Meet.. then it's likely a bug with our component system. Are the streams from the same participant? If you can include the bits of code that is publishing, that'd be helpful to see
CC: @polite-kilobyte-67570 @eager-zoo-16408
a
This is the code responsible for publishing the tracks:
Copy code
buffer := NewBufferReader(10, track.ctx)

localTrack, err = lksdk.NewLocalReaderTrack(buffer, webrtc.MimeTypeH264,
	lksdk.ReaderTrackWithFrameDuration(time.Second/15),
	lksdk.ReaderTrackWithOnWriteComplete(track.onTrackFinished),
)

_, err = room.LocalParticipant.PublishTrack(localTrack, &lksdk.TrackPublicationOptions{
	Name:        track.name,
	VideoWidth:  1280,
	VideoHeight: 720,
})
The
track.name
is a unique value for every video string. For example
thermal
,
left
,
right
and
back
. Attaching a screenshot of our own web-layout where these names are seen being used.
NewBufferReader
creates a thread-safe buffer that implements
ReadCloser
. It is simultaneously filled up by the incoming h264 packets over RTSP while livekit reads from it. Sometimes packets are split-up when the H264 packets are bigger than what livekit requests to read. Let me know if you need this code as well.
👍 1
Livestreaming like this works really really smoothly. We are still super impressed by the quality and latency
❤️ 1
e
Hello @adorable-house-73941, we are able to reproduce this and are looking into it. Thank you for bringing this to our attention. 🙏
a
Amazing! Thank you so much 🙏
d
Thanks for sharing this Sijmen, this is a pretty neat way to convert RTSP directly to WebRTC!
e
fyi @adorable-house-73941, a fix for your problem should land soon: https://github.com/livekit/components-js/pull/618
😍 1