LiveKit Community

it’s possible, but I believe it would require some work to implement on-ice-candidate, on-negotiation-needed, etc

I'm not a Go dev, and I've been battling my way through this in my go participant implementation, so I've decided to ask. From the `OnParticipantConnected` callback, how would one get the room instance &amp; be able to load the `room.LocalParticipant`? I'm having a hard time wrapping my head around it. Any code example would be really wonderful. :slightly_smiling_face:

To provide a bit more context, I'm joining the room by calling `lksdk.ConnectToRoomWithToken(host, token, roomCB)`

For info :
```roomCB := &amp;lksdk.RoomCallback{
		OnParticipantConnected: handleOnParticipantConnected,
	}```


What do you mean by “run through the instance directly”?

Where exactly are you seeing this? ie what connection is timing out?

And I’m only assuming it’s because of the device change but I’m not sure.

Oh, you’re seeing this in users who reconnect

in the logs around the same time I’ve found this
```INFO	livekit	rtc/participant_signal.go:187	could not send message to participant	
{
    "room": "260551fe-777a-4046-876f-f23eef8b0b64",
    "roomID": "RM_jF6hZXvg8H7y",
    "participant": "dd44a41e-8d75-41f4-8c1f-2b19d9263f4d",
    "pID": "PA_hUkwX6xcYSKx",
    "remote": false,
    "message": "*livekit.SignalResponse_Leave",
    "error": "channel closed"
}```

huh, weird. What SDK are these clients on?

so it’s the same user, two different devices, both devices using the React SDK — are the users connecting with the same token? if they’re not using the same token, are both tokens generated with the same `identity`?

<@U02EJ2AP755> which version of the server are you running.. and are you running in with redis or without?

<@U02MC5V3C2H> they are using the same identity, but they are closing one window before opening another.

<@U01KZ61GV5Z> we’re running without redis (should we?) and we were running 1.3.1 but just upgraded to 1.3.3 tonight. The problem was on 1.3.1, we haven’t had it on 1.3.3 so far.

yeah, I think the issue you've hit is <https://github.com/livekit/livekit/pull/1237|this>. it's fixed in 1.3.3. thank you for confirming that.

thanks <@U01KZ61GV5Z> that’s fantastic!

<@U044WK0UDA7> just trying to understand: are you trying to access a the raw RTP packets from the TURN servers? As far as I know, TURN would be passing through DTLS-encrypted packets.

It doesn't seem possible to be able to decrypt the DTLS payload without the negotiated key. Are you decrypting it somehow first?

I’m trying to intercept the srtp packet, perform some modifications to the underlying video stream and then continue forwarding to the livekit sfu. I was able to unmarshall some of the srtp packet header. Essentially I’m trying to determine if it’s possible to expose the dtls keys to the turn server, via redis or say a ws endpoint and if it is, how inadvisable it is to do so. 

Ah I see. that's an interesting path. it seems possible to expose DTLS keys via redis (so it remains private to your backend).

Another approach I've considered is using the peer connection interceptors, defined <https://github.com/livekit/livekit/blob/25debc6d35f5b82e65d76c13b653ee9308a73b05/pkg/rtc/transport.go#L293|here> using the <https://github.com/pion/interceptor/blob/master/interceptor.go|interceptor api>. Where I could define a relatively general plugin model. Are you aware whether these interceptors are post dtls termination?

yes of course! I should've thought of that. Interceptors should work for it. they work on the RTP stream (after DTLS termination).

SRTP does not encrypt RTP header and header extension. So you should be able to unmarshal without decryption.

But a few things to keep in mind
• DTLS should not be in the picture once SRTP keys are set up. RTP streams will use the SRTP context. But decryption should not be necessary to look at just header.
• TURN will have STUN header. You will have to parse past that in TURN server to get to the packet.
• The parsed values do not look correct. RTP version should be 2.
• RTP header extension id is not fixed. Different browsers could use different id for the same extension. You will have to use SDP to get the right id.
• Modifying the packet (something in the RTP header or extension) will break authentication check. RTP payload is encrypted. But the whole packet (including header) is authenticated. So, modifying RTP header/extension before SRTP auth check/decryption will break that.

Thanks for your responses <@U02CM28PB4Y> and <@U01KZ61GV5Z>.
I'm getting more sane rtp header values with the packetdump interceptor (see example log below). Interceptors seem to be the most straightforward way to modify the payload without having to worry about SRTP auth.

Initially I would plan to forward the rtp packet on a new track to an existing peer connection, following the<https://github.com/cloudwebrtc/pion-webrtc/tree/master/examples/rtp-to-webrtc| pion rtp-to-webrtc> example. Then set the interceptor output payload to the modified rtp payload, updating necessary headers. Enforcing, in livekit config and/or interceptor PeerConnection sdp appropriate codec/parameters.

```livekit_server_1  | RTP PACKET:                               
livekit_server_1  |     Version: 2                            
livekit_server_1  |     Marker: false                         
livekit_server_1  |     Payload Type: 63                      
livekit_server_1  |     Sequence Number: 46521                
livekit_server_1  |     Timestamp: 3330104184                 
livekit_server_1  |     SSRC: 3676080904 (db1c8b08)           
livekit_server_1  |     Payload Length: 41  ```

The one thing that makes me hesitant about this approach is that it could lead to osi cross contamination. Do either of you know whether the sdp is fully inferable from the Particapant  metadata from the server api's? From a quick look it does look like that's possible.

One other question I had is whether you would expect to see the extension headers in the logs defined <https://github.com/pion/interceptor/blob/a82b843030a8e8a046cbda37ce33a100ddb3b5f1/pkg/packetdump/format.go#L22|here>? However I don't think getting these is critical as I would pass the TransportParams directly to the Interceptor.

Participant info does not have all the information from SDP, for example things like RTP header extension ids are not available in participant info.

The formatting part is an implementation you can add. The default one is the one you have shown above which just prints the RTP packet.

I think I should rephrase that between the server_sdk and the <https://github.com/livekit/livekit/blob/81fb1c5ef01a2022d90852413679eb17cd6e03ec/pkg/rtc/config.go#L30|WebRtcConfig>. I think I can get the header extensions in particular from the DirectionConfig but it does look like there could be separate configuration that might not be inferable.

If not (and probably even if so), I imagine the peer connection is the better abstraction to be working with, rather than the raw rtp streams. And just implement the track routing as needed, based on some provided configuration.

And to do that I can probably just use the server-sdk.

I believe it is 64K Pat. That is the maximum for Pion.

<@U02GP9AENTH> is that correct?

Both browser and pion has a 65535 limit, livekit protocol will consume a few bytes, so 65000 is a safe value.

Thanks a lot for the info folks! Much appreciated. Time to split up some of these msgs.

you could supply turn servers to the client side vs overriding it in the server logs

hey, sorry for missing this one, at the moment native doesn’t have support for directly setting the video codec. you can try limiting the codecs at the room level:

<https://github.com/livekit/livekit/blob/e31b25300d79b9fb7f32d4b83847d13dae529631/config-sample.yaml#L138>

oh forgot about this: there is actually a way to force the video codec to h264 here:

<https://github.com/livekit/client-sdk-android/blob/main/video-encode-decode-test/src/main/java/io/livekit/android/videoencodedecode/WhitelistSimulcastVideoEncoderFactory.kt|https://github.com/livekit/client-sdk-android/blob/main/video-encode-decode-test/s[…]roid/videoencodedecode/WhitelistSimulcastVideoEncoderFactory.kt>

you’ll need to copy this class and pass that as an override to the LiveKit.create function. set the whitelist to “H264” and it’ll force H264 to be used if it’s available.

That said, it’ll force all video tracks published from the device to be h264, so it’s a bit unwieldy

When participant is `nil`,  it means the data was sent using a Server SDK: <https://docs.livekit.io/server/room-management/#senddata|SendData>

Interesting, it seems like the Go SDK never adds the participant, even when using as a client.

Hey <@U01KZ61GV5Z>, not sure if you've ran into this issue, but I cannot seem to be able to receive a participant ID from the Go SDK

Okay, Sorry, the onDataReceived finally works in Go. Sorry, this was my bad.

From what I understand and getting is on the Client SDK.. if using GO as Client SDK and it executes a `LocalParticipant.PublishData` then on the JS Client SDK, I'm never receiving the Participant data

<@U01KZ61GV5Z> could you tell me, Is that expected?

client sdks should behave the same.. it's possible it's a bug with go sdk during publishing

Okay, I wasn't going crazy then ahah Thanks <@U01KZ61GV5Z>

<@U01KZ61GV5Z> Finally I found the issue. And its coming from the JS Client Side...  In my case, the `participant` is a hidden participant and at this specific line <https://github.com/livekit/client-sdk-js/blob/a1b34d2af7b7e101041b37a9154663a0210c8cfe/src/room/Room.ts#L990>, well the system can't find the actual participant, so it returns `undefined`. Not sure of the proper fix though.

I'm wondering if we could maybe have something such as:
```const participant = !userPacket.participantSid
  ? undefined
  : this.participants.get(userPacket.participantSid) 
      ?? this.createParticipant(userPacket.participantSid);```
Or something.

For the time being, this works for me, and I get the participant obj. :slightly_smiling_face:  Although my only concern is maybe you guys were only doing the get, to make sure the participant actually exists. :man-shrugging:

<@U032TUAL4KT> I think this is the right behavior.. if the publisher is hidden, then we can't really attribute any participant to it.

Actually this seems to be a side effect. it's debatable whether a hidden participant should be able to publish data to others. We currently do not prevent it; but it seems that the behavior is kind of confusing.

For me, this is a server state participant, hence the hidden, but this one pushes Data to all or specific participants.

You could probably get a server SDK to add participant MetaData onConnect

Actually you could add a parameter in the metadata on the token creation, then check upon that value on the client side to show the screenshare button.

Yes this was our first design! We refactored it to not store the permissions on the metadata, because when calling UpdateParticipant (server-sdk) we also had to update the metadata. Also became the case that we were sometimes looking up the permissions on the metadata and sometimes on the Participant.permissions obj, so kinda became a mess. But we’ll reconsider it, maybe only for the roomAdmin. Thanks for your fast response sir! :slightly_smiling_face:

Hey <@U01KZ61GV5Z>, Could you please share why the `latency` metric was dropped in this PR: <https://github.com/livekit/livekit-cli/pull/101/files>?

Hi Livekit
<https://livekit-users.slack.com/archives/C01KVTJH6BX/p1673420698267789>

image.png

For localTracks the muted state doesn’t get sent back to the client afaik. For remote tracks, those two fields will be the same, for local tracks it’s safe to rely on the `isMuted` one.
Generally you shouldn’t have to access the trackInfo directly, is there something specific you’re trying to do with it?

Yes. Because it is impossible to get mute status for unsubscribed user.

your haproxy config is incorrectly assuming TURN/TLS is http:
```mode http
server app-01 10.0.0.20:5349```
I'm not familiar with haproxy setup, but I think you'll need to use sni (level 4 TLS termination) instead.

<@U01KZ61GV5Z> Thanks for a quick reply! We’ve changed haproxy mode to tcp:

```frontend turn_livekit
bind 0.0.0.0:5349
mode tcp
default_backend turn_livekit_backend
maxconn 65000

backend turn_livekit_backend
#mode http
mode tcp
#server app-01 10.0.0.20:5349
server app-01 10.0.0.20```
Our current TURN config:
```turn:
  enabled: true
  domain: <http://turn.xyz.com|turn.xyz.com>
  tls_port: 3478
  cert_file: /working/path/to/cert
  key_file: /working/path/to/key
  external_tls: false```
Unfortunately with no effect :confused:

1. For long sessions (especially 10+ hours), I’d recommend using HLS/m3u8 with a longer segment duration as you said. If you really need to stick to mp4, you could try using VideoCodec `H264_HIGH` for better compression and lowering the resolution and/or bitrate, but I think the files would still be pretty massive.
2. Do you have any errors from the egress logs? I haven’t seen upload issues on our end, it might be object storage or rate limit related

Quick update: According  to Lionde support, there direct max file size is 5GB (in Object storage for a single file), if we need to upload more than 5GB+ files we need to upload using *multipart uploads.* Does you guys support multi upload for S3 API compatible object storage in egress when uploading files to object storage ?

Let me try get logs as in tests we use k8s extend pods (scaled up worker nodes) which destroyed once the tests are complete. Let me do few checks on long duration and share egress service logs.

 Is above 10 hrs+ (~12-15 GB) and 24hrs+ (37-40 GB) file size is norm for mp4 recording generation with egress service in your experience <@U01UB0LHTTQ>?

We don’t currently support multipart uploads, but it’s something we should be able to add.

A 10 hour, 1080p, 30fps mp4 at 3 Mbps would be about 13.5GB, so those sizes seem normal

Noted with Thanks.

It will greatly appreciate if you guys can enable multipart upload support in egress service. Although, we use HLS/m3u8, still those files  will generate same size (as of mp4) with for long duration sessions. Customer always prefer to download files in mp4 format, so later we need to convert HLS/m3u8 files into mp4 again, which will lead double effort.

running long recordings with mp4 is a not a good idea from a reliability perspective. if your servers fail for any reason, you'd lose the entire recording.

Oh yes, got it <@U01KZ61GV5Z>, Thanks.

So do you guys have any recommendations any oss or SaaS on converting HLS to mp4 later on reliably for longer duration sessions?

Our idea is once the egress request complete ( upload complete to object storage) triggered ( via webhook - if it supported), we trigger a pipeline to convert hls to mp4 ( via set job in k8s) as well.
Our initial idea is to use docker of ffmpeg or gstreamer ( as you guys utilized in egress) and run parallel jobs per instance.
Or use media conversion via AWS or GCP SaaS and serve the content via GCP/AWS CDN service (more expensive).

<@U01UB0LHTTQ> egress logs:
```	"error": "S3 upload failed: EntityTooLarge: \n\tstatus code: 400, request id: tx00000000000000daf7f61-0063c0c74b-5521732-default

	"EG_VT5uS6AWDynn", "request_type": "room_composite", "output_type": "file", "status": "EGRESS_ENDING"}
	2023-01-13T08:19:43+05:30 2023-01-13T02:49:43.901Z	DEBUG	egress	pipeline/pipeline.go:469	sending EOS to pipeline	{"nodeID": "NE_XoKS6EGEr4HR", "handlerID": "EGH_R7pj2YudsxyX", "egressID": "EG_VT5uS6AWDynn"}
	2023-01-13T08:19:44+05:30 2023-01-13T02:49:44.079Z	DEBUG	egress	pipeline/pipeline.go:290	EOS received, stopping pipeline	{"nodeID": "NE_XoKS6EGEr4HR", "handlerID": "EGH_R7pj2YudsxyX", "egressID": "EG_VT5uS6AWDynn"}
	2023-01-13T08:19:44+05:30 2023-01-13T02:49:44.463Z	DEBUG	egress	pipeline/pipeline.go:641	pipeline stopped	{"nodeID": "NE_XoKS6EGEr4HR", "handlerID": "EGH_R7pj2YudsxyX", "egressID": "EG_VT5uS6AWDynn"}
	2023-01-13T08:19:44+05:30 2023-01-13T02:49:44.604Z	DEBUG	egress	pipeline/pipeline.go:668	uploading to s3	{"nodeID": "NE_XoKS6EGEr4HR", "handlerID": "EGH_R7pj2YudsxyX", "egressID": "EG_VT5uS6AWDynn"}
	2023-01-13T08:19:48+05:30 2023-01-13T02:49:48.084Z	INFO	egress	utils/cpu.go:77	high cpu load	{"nodeID": "NE_XoKS6EGEr4HR", "load": 0.9185185185185185}
	2023-01-13T08:21:55+05:30 2023-01-13T02:51:55.411Z	INFO	egress	pipeline/pipeline.go:691	could not upload file	{"nodeID": "NE_XoKS6EGEr4HR", "handlerID": "EGH_R7pj2YudsxyX", "egressID": "EG_VT5uS6AWDynn", "error": "EntityTooLarge: \n\tstatus code: 400, request id: tx00000000000000daf7f61-0063c0c74b-5521732-default, host id: ", "location": "S3", "filepath": "egress-loadtest-k8/room-composite/2023-01-12T23_19_38Z-mp4/room-composite-egress-test_mp4_2023-01-12T23_19_38Z-mp4_1.mp4"}
	2023-01-13T08:21:55+05:30 2023-01-13T02:51:55.413Z	DEBUG	egress	pipeline/pipeline.go:668	uploading to s3	{"nodeID": "NE_XoKS6EGEr4HR", "handlerID": "EGH_R7pj2YudsxyX", "egressID": "EG_VT5uS6AWDynn"}
	2023-01-13T08:21:56+05:30 2023-01-13T02:51:56.084Z	DEBUG	egress	pipeline/pipeline.go:731	removing temporary directory	{"nodeID": "NE_XoKS6EGEr4HR", "handlerID": "EGH_R7pj2YudsxyX", "egressID": "EG_VT5uS6AWDynn", "path": "/tmp/lkegress/EG_VT5uS6AWDynn/"}
	2023-01-13T08:21:56+05:30 2023-01-13T02:51:56.714Z	WARN	egress	service/handler.go:121	egress failed	{"nodeID": "NE_XoKS6EGEr4HR", "handlerID": "EGH_R7pj2YudsxyX", "egressID": "EG_VT5uS6AWDynn", "egressID": "EG_VT5uS6AWDynn", "request_type": "room_composite", "output_type": "file", "error": "S3 upload failed: EntityTooLarge: \n\tstatus code: 400, request id: tx00000000000000daf7f61-0063c0c74b-5521732-default, host id: "}```
it seems the *culprit* is indeed the *object storage limitation with single upload API* cmd (without support for multi-part upload)

Capture_2023-01-13-004.png

Capture_2023-01-13-002.png

Capture_2023-01-13-003.png

Capture_2023-01-13-001.png

Capture_2023-01-13-005.png

<@U01UB0LHTTQ> <@U01KZ61GV5Z> At the moment, in zoom for free tier, the recordings are save in .zoom format(Assume this is m3u3 - TS files) and once user click on on one of the *.zoom file it automatically create the mp4 file from existing files. Can we embed such script(s) (to support in win and *nix kernal OSs) with egress upload which allow to convert m3u8 to mp4 by clicking the script after user  download all HLS / m3u8 files of his/her recording to local device.

created a couple issues to track:
<https://github.com/livekit/egress/issues/215>
<https://github.com/livekit/egress/issues/216>

<@U01UB0LHTTQ> <@U01KZ61GV5Z> Can we get EGRESS_FAILED event into livekit-server webhooks (<https://docs.livekit.io/server/webhooks/#egress-started>), which will help developers to handle ERGRESS failed scenarios such as  ;
• trigger another request based on the failed reason / scenario
• inform customer about the recording failed.

it will send an egress ended webhook, and you can check `egressInfo.Status` for `EGRESS_FAILED` along with an error message in `egressInfo.Error`

an ffmpeg based service/command can convert hls to mp4 fairly easily. You'll still have to deal with massive files adterwards.

Yes <@U03H6MNQ9G9>, what we decide is to give 'convert to mp4' option, where users who need to have the mp4 can request to convert the file and will use compression as <@U01UB0LHTTQ>  suggested and to convert keeping the quality and size in balance , compress the file with tar.gz as well for now.

You may have operational reasons to put the resulting media in gziped tarball, but gzip will not give you any further compression

Thank you for your update.

Do you any have any insights/ suggestions to futher optimize  the process or better solution that we can follow ?

<@U01UB0LHTTQ> any update on the following issues;

<https://github.com/livekit/egress/issues/215|https://github.com/livekit/egress/issues/215>
<https://github.com/livekit/egress/issues/216|https://github.com/livekit/egress/issues/216>

Hey Ashan, these are on the roadmap but the team does not have any time to look into them in the next month or so. If #215 is a blocker for you, I would encourage you to submit a PR! It should be well contained in the upload path

Sure <@U01KZ61GV5Z>, I'm no GO expert at the moment, but will try to go through issue and share feedback.

What would be the root cause for this issue?

maybe <@U02CM28PB4Y> has useful commentary here

it's not clear to me what the issue is.. can you provide repro instructions using our sample app?

<@U01KZ61GV5Z> I didn't try to use your sample app

also.. running 10 users on the same machine is likely going to overwhelm some resources here.

Unfortunately we aren't able to help debug application side issues. We can do what we can with issues related to the SDK and/or backend components.

If the issue is with the SDK/server, it should be reproducible with our sample apps. So I would suggest trying that first

I think this is livekit server response issue.

As you can see, it's showing local track published correctly. But opposite side is not getting trackpublished event for the video

Yeah, overloading PC will present some interesting challenges.

Like David mentioned, if you can reproduce using sample app and provide repro instructions, it will help us repro it and address it.

<@U01KZ61GV5Z>
I was testing with 8 users in a room. And I tried to reload 8 users at once. But after I reload all, it's showing blanking users
What's the root cause for this issue?

Hi LiveKit,
I have some issues when connect to room in React.

```const roomState = useRoom(roomOptions);
useEffect(() =&gt; {
    console.log('live kit useeffect');
    roomState.connect(url, token, connectOptions).then((room) =&gt; {
      console.log('room', room);
      if (!room) {
        return;
      }
      if (onConnected &amp;&amp; room.state === ConnectionState.Connected) {
        onConnected(room);
      } 
    });

    return () =&gt; {
      if (roomState.connectionState !== ConnectionState.Disconnected) {
        roomState.room?.disconnect();
      }
    };
  }, []);```

saw that you solved it already, this is due to a workaround to make react work in strict mode

Screenshot 2023-01-13 at 8.30.26.png

I think I understand your desire, that makes sense.

Though this seems rather complicated and it'd fairly difficult to implement in a clean way.

Noted <@U01KZ61GV5Z>. 

Can i suggest the following to simplify the process and let us know your valuable revert feedback;

• We introduce *priority* attribute for egress service config.
• By default, if the priority is not set, it will assign "0" by default, which is highest priority ( to a server or cluster) and likewise one can set a priority number for the egress service cluster / docker / node.  Eg : As of DNS - MX. records one can add multiple entries with priority and lowest will give highest priority while largest will have lowest priority.
• When routing happens ( on egress requests) , apart from *current routing logic we sort the egress available workers with priority* ( as point 2 logic) and serve first available worker.
We can keep egress node / cluster priority attribute in redis as well.

Hey there, these are asynchronous calls. You probably need to async/await them or chain them in promise callbacks. For network requests, you can’t be 100% sure of the order these operations arrive and execute on the server.

In desktop livekit client it works as expected 

I’m not familiar with RN, so maybe there’s something about it I don’t understand. cc <@U01NZKTNE1H> just in case.

Hmm dont know of any differences here that would cause a behavior change here on RN.

that's interesting.. could you file an issue on GH for this? we'll take a deeper look as to what the issue may be.

i guess the problem is with react-native-webrtc or the way I am using it, it doesnt stop the previous negotiation when I start another in between the first negotiation, or doesnt synchronize the 2 negotiations.

Our SDK should manage that. If it's in the middle of a negotiation, it would wait for it to be complete before starting another one.

For Kubernetes deploys you'd want to refer to this: <https://docs.livekit.io/oss/deployment/kubernetes/>

I was referring to that, but it’s not very detailed, for a person new to kubernetes or GCP it’s very hard to get started. For example I’m not sure where I should run the helm and kubectl commands, and how to configure the k8s cluster

Hi, Kubernetes is not for the faint of heart :sweat_smile:  our guides are certainly not designed for those that aren't already running Kubernetes on their own.

To get a basic instance running, you'd want to follow the <https://docs.livekit.io/oss/deployment/vm/|standard VM deployment>. If there's anything unclear, please let us know.

You can override tag value with override yaml install latest version for your k8s deployment

I am using `helm repo update` and `helm upgrade` . How can I override tag?
like this?
`helm upgrade ... --set &lt;service&gt;.appVersion="v1.3.3"`

via values.yaml (<https://github.com/livekit/livekit/blob/master/config-sample.yaml>)

```replicaCount: 1

# Refer to <https://docs.livekit.io/deploy/kubernetes/> for instructions

image:
  tag: v1.3.3 
....```
or

`helm upgrade ... --set image.tag="v1.3.3"`

hey <@U04HZ52BXFD>
to answer your questions:
1. explicitly unpublishing a track is not what we would generally recommend, `set*Enabled` effectively only mutes a track, so you won’t get `trackUnpublished` events. If you _need_ to unpublish tracks you would do so by calling `localParticipant.unpublishTrack(track)`
2. the recommended approach is to restrict this via the `token` grants. 
3. that’s just an artifact of the fact that `LocalTrackPublication` inherits from `TrackPublication` . it does not consume any additional bandwidth. 
4. That’s a good point, we’ll have some news this week about a new - more consistent - approach to this. 
5. For remote tracks you can do so via `track.setVolume` (you can even do this on the `remoteParticipant.setVolume` . for local tracks it’s a bit more tricky and we haven’t exposed any APIs (yet) to make that happen out of the box
6. cc <@U02MC5V3C2H> 

Hi <@U02EU2ZPTQU>

1. What is the difference between `setEnable(false)` vs `unpublish(track)`? More importantly, for the first one, when muted, does it also transmit 0 bandwidth?
2. Got it.
3. Ok
4. Can't wait for it :slightly_smiling_face:
5. Ok will wait for this feature to adjust volume from publisher side.
More questions:
7. Say if I want to manually call `localParticipant.unpublishTrack(track)` , does it affect livekit features such as `adaptiveStream`/`dynacast`/`simulcast`
8. Is it possible to get the actual display resolution of a published video track? For example, the user might select 720p, but if the user does not have a camera with that quality, the actual displayed quality would be say 480p. It would then be useful to display this quality value to the publisher so that they know.
9. How to set/change device after creating/published track?

1. <https://docs.livekit.io/client/receive/#enabling/disabling-tracks>
7. you will have to manually re-publish the track when needed, `set*Enabled` are convenience methods that take care of that for you.
8. <https://docs.livekit.io/client-sdk-js/classes/LocalVideoTrack.html#dimensions>
9. <https://docs.livekit.io/client-sdk-js/classes/Room.html#switchActiveDevice>

Hey how can I check if `adaptiveStream`, `dynacast` and `simulcast` are active? My setup is like this:
```useRoom({
      adaptiveStream: true,
      dynacast: true,
      publishDefaults: {
        simulcast: true,
      },
    });```
For example when I check `localVideoTrack?.isSimulcast` it returns `false` event though I set it to `true`.

Also, `switchActiveDevice`only switches device for published video (on remote side) but not on localVideoTrack side. How to make it work for local as well?

switching devices on tracks themselves can be achieved with <https://docs.livekit.io/client-sdk-js/classes/LocalVideoTrack.html#restartTrack>.

What publishing quality do you have on your tracks? there are certain browser restrictions around simulcast (e.g. a 320x180 video cannot have simulcast layers, only larger ones). For chrome these are defined here: <https://chromium.googlesource.com/external/webrtc/+/branch-heads/51/webrtc/media/engine/simulcast.cc#39>

1. I tried both `await room?.localParticipant.enableCameraAndMicrophone();` and manually
```const videoTrack = await createLocalVideoTrack({
              facingMode: "user",
              resolution: VideoPresets.h720,
            });
await room.localParticipant.publishTrack(videoTrack);```
, both on chrome. and `isSimulcast` still returns false. Other than that, how can I check for `adaptiveStream` and `dynacast` as well?

2. How to get video quality from remote video track?

I tried `RemoteTrackPublication.videoDimension` but its protected, I tried ``RemoteTrackPublication.videoQuality`` but its a single digit like `2`. Possible to get width+height like 1080p or 720p?

3. For livekit cloud, if I call server functions such as `list-rooms` or `list-participant` , does it count towards the API rate request limit? <https://docs.livekit.io/cloud/quotas-and-limits/#api-rate-requests>

Screenshot from 2023-01-16 16-12-55.png

Please thread your messages, thanks! :pray::skin-tone-4:  

The sdk will give up if failed after 10 times retry, the client need call connect manually in this case

But how can  we know it's giveup already?

it will fire a `RoomEvent.Disconnected` if all reconnections failed

clipboard_1673589710199.png

looks like you’re running this against a local livekit-server, do you have `insecure` set in your config?

The config for my egress service shows above.

<@U01UB0LHTTQ>, the insecure is set to true by default in my config.

what environment are you running on? I cannot reproduce this

The egress service is running in a redhat 8.3 environment.

<@U01UB0LHTTQ> ，what's your environment used to test?

I test on M1 mac and a debian 11 test machine

I tested on x86 platform,  it works. Looks it is a issue in ARM system.

Ah, we only build arm64 (for development on M1s) and amd64

By checking the install-chrome script, for amd64, we installed the google-chrome, but for arm64 system, we only installed bunch of libs, what's the reason behind it?

Chrome for arm64 doesn’t include h264 support, but amd64 chrome does. So for amd64 we can just install it directly, but for arm64 we had to build chrome ourselves with h264 enabled. The custom build for arm64 is copied over here <https://github.com/livekit/egress/blob/main/build/chrome/install-chrome#L6>

the arm64 build itself is not committed to the repo (because it’s huge), but the build steps we’re using can be found here <https://github.com/livekit/egress/blob/main/build/chrome/README.md>, and you can find the build in the `livekit:chrome-installer` docker image under `/chrome-installer/arm64`