LiveKit Community

If anyone having this porblem then downgrade to Firefox: 99 &amp; it should be working. Not sure if from pion side require to update anything or not.

is it consistently reproducible on FF? I can't think of any server-side changes that could've caused this. This is likely an encoder-side issue. One thing to perhaps try is turning off opus DTX to see if problems persist

<@U01KZ61GV5Z> yes, I've tried from 3 devices &amp; faced similar problem. But no problem with `mediasoup` . That's why thought might be some problem from server side.

I am not able to reproduce this running server locally.

My test
• LK server running locally on my MAC
• Connect to it from Firefox 100.0 (64-bit)
• Connect Chrome using JS SDK sample app to the same room. Mute microphone of this participant.
• Listen to audio from Firefox participant.

<@U02CM28PB4Y> Thanks. Can you try both user join from Firefox? From my side I tested as your description but couldn't hear any sound to Chrome.

I can reproduce this.. it seems to be a client-sdk compatibility issue with FF 100.

this should fix it.. if you wanna verify locally: <https://github.com/livekit/client-sdk-js/pull/224>

<@U01KZ61GV5Z> thank you. Updating you shortly

<@U01KZ61GV5Z> thank you. It's working perfectly! :tada:

thanks for the quick verification! :thumbsup:

<@U01KZ61GV5Z> if possible publish in npm soon as it's an important patch!

I should also specify that I didn't use the network host mode and exposed the needed ports as I have a requirement on that front.

I actually made to get tcp traffic for the turn sercver to reach it, but the turn server is configured to establish additional ports in the range 1024 30000 <https://github.com/livekit/livekit-server/blob/master/pkg/service/turn.go#L44-L46> and I cannot expose those ports. Should be possible to configure them somehow?

スクリーンショット 2022-05-11 11.03.15.png

Hi Brian, sorry for the issue but very interesting.

Can I have your iMac model number ?

The default `CameraCaptureOptions` requests 30 FPS and it looks like your iMac limit is at 29 FPS. My assumption that all Apple devices support 30 FPS isn’t great.

I might modify `CameraCaptureOptions.fps` to `CameraCaptureOptions.preferredFPS` and make it fit within the supported range.

Meanwhile, you can try to create a camera track with 29 fps:
`let track = LocalVideoTrack.createCameraTrack(options:CameraCaptureOptions(fps: 29))`
and Publish it:
`Room.localParticipant.publishVideoTrack(track)`

Update: changes have been merged <https://github.com/livekit/client-sdk-swift/pull/86>

Wow thanks for the fast turnaround! Does that mean a new version of the Swift Package is forthcoming? Or what's the best way to make use of the updated code?

for now, you can point to master in your swift package config. we will be releasing a new version in the next few days!

image.png

hey <@U03B07G8WLC>, I think this might be the same? <https://github.com/livekit/client-sdk-flutter/issues/114>

Hi <@U01NZKTNE1H>, yeah I have exact same issue ) I tried to workaround it by directly calling SendData on Server API(<https://docs.livekit.io/guides/server-api/#senddata>), but there my request data can't be decoded. Here is what I'm doing  :
REQUEST : POST &lt;https://**/twirp/livekit.RoomService/SendData&gt;
REQUEST BODY : {"room": "room.id or room.name I tried both"  ","data": my message's bytes ,"kind":"reliable"}
And I'm getting this error :
RESPONSE BODY : {"code":"malformed","msg":"the json request could not be decoded"}

Hey Will, how are these users joining? I think it's likely hitting a race condition with multiple users joining at the same time with the same identity. This seems pretty hard to run into in practice. Is this an expected use of the product in your application? normally duplicate identity means the user is refreshing *or* opened the window in a new tab.

When each participant connects, it'll connect with a new SID, and we'd issue a signal command to disconnect the previous user.

I'm pretty sure this is a codec-related issue.. can you try limiting your livekit server to <https://github.com/livekit/livekit-server/blob/master/config-sample.yaml#L108|only accept vp8>?

hello #devid i am very new to flutter and livekit so i cant understand so much things. i want ask that is this a device spacific issue ?? means its only happening in Samsung galaxy A7 tab when i call to or from this samsung A7 tablet the another device cant able to show videotrack of this tablet..

each device supports different codecs.. my guess is A7 tab doesn't support H.264 very well

<@U01KZ61GV5Z> thank you so much for your helpfull reply its working totally fine now

Hey Luis, this seems to be working fine for me. did you change the capture settings? i.e.
```new Room({
  videoCaptureDefaults: {
    resolution: VideoPresets.h1080.resolution,
  },
}```

Hi David, yes, I did – just like in your example as defaults, but also in the createLocalTrack options. And for debugging purposes I also tried higher default resolutions (with virtual cameras that should support e.g. 4k). When inspecting the track info, I can see the correct resolution (e.g. 1920x1080), but looking at stream info on the receiver side, it‘s scaled down to 1280x720. 

could you share the code snippets for both setting publishing options, but also how you are publishing the tracks? I've checked with the sample JS app that we are receiving the correct resolution that's published.

I’ve just connected to <http://example.livekit.io|example.livekit.io> with various devices and cameras and was also restricted to 720p. Is the example client configured to allow higher resolutions? If yes, that points to an issue with my server config.

Never mind, I think this is an issue with my new MacBook (as well as virtual cams).. :man-facepalming: My previous tests with this new MacBook (1080p FaceTime camera &amp; multiple virtual cams up to 4k) and a previous MacBook (720p FaceTime and the same virtual cams) were limited to 720p. Additional tests with a higher-res iPad camera (I’m not sure about the exact resolution, but it’s way above 1080p) and another Mac with a 1080p and a 4k HDMI capture device were now successful.
Digging further, it looks like the FaceTime HD cam on the new MacBook Pros, even though it’s specced at 1080p, only advertises 720p to browsers, so that explains that. I’ll now investigate the virtual cams and let you know about my findings.
If anyone with a new MacBook Pro M1 could also test their max resolution (in a browser) and post the results, that would be very helpful!

hah, I didn't even think of that. most of us here have external webcams that are 1080p+. tho also confirmed M1 MBP Webcam can capture at 1080p just fine.

Quick update: Rebooting the system helps to make both the M1 Pro Facetime HD and virtual cams available with their full resolutions again. I‘m trying to reproduce the problem and post an update once I succeed.

hey <@U03EKGG48AG>, I’d probably skip using `LiveKitRoom` and use `VideoRenderer` and `AudioRenderer` + `useParticipant`

You can look through an example of me doing some more custom stuff here (no solid documentation yet for this, sorry (!), but on my list of TODOs):
<https://github.com/livekit/hq>

Thanks <@U028SSAKLQ1>! I can’t take credit though. It’s the great work of <@U02U5DXF41H>, which I forked and reworked to use LiveKit for audio and video. I do have some plans (my overall TODO list is getting a bit unwieldy… =)) to add some features to it eventually.

Oh, I was looking at this, it looks super fun <@U01KZ0SCDKL> 

<@U03EKGG48AG> &lt;ParticipantView&gt; works great for me so far.

<@U02KJGV339S> just checking, are you using adaptive stream?

there had been a few rendering changes, so I'm trying to understand which combination of options would reproduce the failure.

hello, neither simulcast nor adaptive stream

oh and the frozen video is on the android side, web renders both it’s own feed as well as the android video feed just fine

if I switch android’s sdk version back to `0.9.1` there’s no issue

for the web client frozen video, the bug should be fixed shortly

for the back camera issue, is it just that the event is missing, or do other participants not see the video either?

no, it’s the event, on web I do get the android video feed but in the android side I don’t get the `TrackPublished` event

is it possible that you've got the events collection setup after the enabling of the camera?

or does this only happen for when you're on the device with back camera only?

hmm I do, but on the older version it does triggers, and the audio track also triggers in both the old and new versions, I haven’t checked with the device that has both front and back cameras

I can check that Monday morning if it’ll help

sorry yeah, forgot, and yes it happens on both devices, the one with front and back cameras and the one with only back camera

hmm I'm thinking this might have just been a race condition with undefined behavior

Screen Shot 2022-05-15 at 1.47.07 AM.png

Screen Shot 2022-05-15 at 1.46.51 AM.png

Howdy friends, i know this question sounds silly, but for some reasons i can’t go past it, i’m recording a room with custom layout and when playing the recorded video there is this weird black border on the right and bottom, when viewing the custom recording layout there is no border, is this a shadow that’s being introduced for some reason?

Yes looking into it. :slightly_smiling_face:
It appears to be an issue at `flutter_webrtc` level. Some thread checks may have changed in Flutter 3.0.

Thanks Hiroshi, I just noticed you had fixed this.

As a follow-up, we thought we could set something special on the recording `participant`’s `identity` and/or `name` and/or `metadata` properties, but we don’t see in the docs how we might do that; i.e. we don’t appear to have any access to those properties through the server-side SDK

hey <@U02KX7RH43Y>, how are you creating this access token?

are you using our recorder or saving these streams with something else?

<@U02L67PHKKN> or <@U02KJGV339S> can you answer this?

the access tokens for our participants are created using the node sdk

Well, except for the recording participant.  That's implicitly created when we request a recording.

as for the recording we’re using `livekit-server-sdk/dist/RecordingServiceClient`

oh and right, we don’t create a participant when recording, it gets added when we start a recording session

And just to clarify, we are using the original livekit-recorder design.  Haven't investigated the new approach yet

I see, that should work just fine. the tokens recorder generates should set both `hidden` and `recorder` fields to true in the access token: <https://docs.livekit.io/guides/access-tokens/#video-grant>

that signals to the SFU to not send updates of that participant to others.

So in theory that participant should not be triggering RoomEvent.ParticipantConnected events on the clients? (because currently, it is)

if the permission bits on the service had been set correctly.. yes

the logic <https://github.com/livekit/livekit-server/blob/master/pkg/rtc/room.go#L723|is here>: fwiw

Thanks David! Is there anything in the docs about how to set the permission bits on the service?

if recording service is creating the token.. it should be <https://github.com/livekit/livekit-recorder/blob/355a538b68a8c9feef6fe65559f2ece6a37e0a13/pkg/recorder/request.go#L107|done automatically.>

`useRoom` will not update on individual participant metadata changes. `useParticipant` will handle these updates.

Actually, the more I am thinking of it, once the room is set to adaptive stream and the suscribers are handled on the client side, correct me if I am wrong, but should be possible.

that's not possible today. For a single subscriber, adaptive stream would have to be turned on for all of the tracks that they are subscribing. it should match the size of the UI element though, is it sufficient to have the participant to occupy a larger UI element?

Although, through code couldn't I force users to always receive the high quality track?

you can def use adaptive stream on only some subscribers, but not others. but for a single user, adaptive stream will be enabled for all of the tracks they are subscribed to

Are you primarily looking for HTTPS termination with SWAG? It should be possible to put the signaling port behind any reverse proxy.

However, WebRTC ports will still need to be exposed and accessible.

Yes that is the intention. I have tried to make it work but I suppose I am struggling with the proxy conf file, as SWAG uses container names to route traffic. See here: <https://github.com/linuxserver/reverse-proxy-confs/blob/master/sonarr.subdomain.conf.sample|https://github.com/linuxserver/reverse-proxy-confs/blob/master/sonarr.subdomain.conf.sample>

I see.. I'm not sure how it works with container names. but it should be similar to other docker containers

Hmm okay i guess il have to keep trying with the config, SWAG may have some docs on making custom proxy conf files

Livekit SDK basically clean up for you. Otherwise:
```room?.off(event, method)```
should work too

it's not possible to clean it up when using anonymous functions.. it'd be better to do something like:
```const metadataHandler = (payload: string) =&gt; {
...
}

room.on(RoomEvent.RoomMetadataChanged, metadataHandler)

//and when you don't need it anymore
room.off(RoomEvent.RoomMetadataChanged, metadataHandler)```

Does it work for someone on windows? Strange thing is the pure WebRTC  Example is working fine. <https://github.com/livekit/client-sdk-flutter/issues/121>

hi <@U03GFCUQUL8>!
yes, this is possible, you will just have to keep track of two separate LiveKit `Room`s.
Depending on your usecase you could also look at manual subscriptions, where all users would still join the same room, but you decide on a track/participant level which users subscribe to which tracks.

Thank you, I am glad that there is support for it :slightly_smiling_face: That’s our use case, I found out that I need to disable `autoSubscribe` to manually subscribe to tracks, docs are clear on this :ok_hand:

Hey <@U03C8KQDJMA>, at some point, we'll make the deployment generator to generate ingress configuration too.

for now, what you need to do is to use an external redis instance instead of bundled (there's an option for that in the config generator)

Then point egress to the same redis instance, and you should be good to go.

Screen Shot 2022-05-20 at 12.23.07.png

Screen Shot 2022-05-20 at 12.20.12.png

are you using the helm charts? if so which version?

Hey Joao, the generated configs do not use Redis.. and thus does not work with Egress. We do plan to update them so it could generate redis-compatible configs too.

For now you can modify the config to use Redis, and then the same api key and secret pairs should work with Egress Client

Thanks <@U01KZ61GV5Z>, re-reading the documentation I could indeed figure that on my own :slightly_smiling_face:, thank for your help, I will follow you sugestion.
I’m trying  local  only tests for now, but latter I will try to deploy this to aws with autoscaling groups. I read the <https://blog.livekit.io/running-livekit-on-aws-7e86849d4a40/|AWS post>, is there any more details regarding using auto scaling with livekit?

I’m using redis now:
```2022-05-25T00:01:26.270Z	INFO	livekit	service/wire_gen.go:132	using multi-node routing via redis	{"addr": "192.168.1.192:7777"}```
but when doing
```egressClient := lksdk.NewEgressClient(host, apiKey, apiSecret)
egressInfo, err := egressClient.StartTrackEgress(ctx, trackRequest)```
I still get an error:
```twirp error unauthenticated: permissions denied```

Nevermind, my egress was not connecting to the redis instance :stuck_out_tongue:

hmm, can you confirm that the key / secret are from your config? feel free to DM me your config if you want another pair of eyes on it.

on autoscale, we recommend going with Kube. standalone VMs are easy to get it running, but autoscaling is a challenge.

at the moment I’m only evaluating livekit, but if this end up in production I confess that I’m a little scared to run media through kubebernetes, but maybe this is just me being  excessively “old school”

You certainly can use LiveKit for this. 

The benefit of using vanilla p2p WebRTC here is you don't have to pay to host the SFU. 

There are some downsides to p2p though, one being, you sacrifice the ability to record calls.

but actually you have to host the SFU to be able to exchange the connection information right?

Rind, in either case you will need a central coordination server with WebRTC. the main difference is whether media flows directly through peers or via an SFU like LiveKit

:wave:  Kenny! Just for clarification, you’re asking whether one participant (client) can mute another one, for everyone else in the room?

Gotcha, at the moment, you can only accomplish this via server SDK. The rationale is, there's a potential security issue with any client being able to affect the track state of others. However, I could see a scenario where certain operations by a client are permitted based on a server-assigned and controlled role.

Ill add my vote to allow this also.

In some cases, if in a room there's a lot of users.. such as in an office, it can be noisy, and i'd be great to allow users to mute that specific user. Similiar to what Google Meet allows.

It’s possible today (have to make an API call), but not as convenient as perhaps it _could_ be. I need to think about it more. :slightly_smiling_face:

It's also possible purely on the front end by sending data and listening for it in other clients

Then like room.on("data") if you are bob, mute yoself.

Good call out.. yeah that's a way to make it happen :slightly_smiling_face: Thanks <@U02BD5MV5NX>

if it's an instance you are not anticipating a lot of traffic, the smallest VM you could find on Digital Ocean, AWS, or GCloud would work well.

it doesn't use a lot of resources (unless it needs to serve many users at the same time)

I've had great luck with $6 instances on Vultr.

after updating ios build target to 13 and copying this from the GH example to podfile all worked well
```
    #
    # Fix deployment target issue
    # <https://stackoverflow.com/questions/63973136/the-ios-deployment-target-iphoneos-deployment-target-is-set-to-8-0-in-flutter>
    #
    target.build_configurations.each do |config|
      config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '13.0'
      #
      # Make it compile with M1 macs
      #
      config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = 'arm64'
    end```

Thanks for the detailed description <@U030F40L81X>! I'm just a contributor (not with LiveKit), so some of my points below could be wrong.
• The issue on egress health-check is best answered by <@U01UB0LHTTQ> 
• I've seen the `buffer too small` issue before when using H.264, is this your case too ? I think we can add the logic to skip pushing that frame to GStreamer when that error is encountered
• I'm suspecting `GStreamer negotiation error` happens when the pipeline isn't valid. Can you tell us more about your setup ? I'm assuming you're doing a `TrackEgress` request with `VP8` as your codec. AFAIK, `VP8` on `TrackEgress` isn't integrated with GStreamer yet, it's currently using Pion's `media.Writer`. I'll look into it this weekend.
• `ListEgress` is probably best answered by <@U01UB0LHTTQ> as well
• Sending NACKs and PLIs on interval is not recommended as it burdens the publishers. LiveKit's sample buffer used by the egress should be sufficient to send PLI on dropped packets. I believe NACK is already handled by LiveKit server
I think it'll be a good idea to open a GitHub issue if possible.

Thanks <@U02SGSET1RT>
&gt; I’ve seen the `buffer too small` issue before when using H.264, is this your case too
I’m mostly seeing this on VP8 as most of our users use chrome.
&gt;  I’m assuming you’re doing a `TrackEgress` request with `VP8` as your codec.  AFAIK, `VP8` on `TrackEgress` isn’t integrated with GStreamer yet, it’s currently using Pion’s `media.Writer`. It’s on the backlog though
Yes, I’m using track published webhook to get the track mime type and send an egress request for the track. For the case mentioned above, it was VP8.
It looks like everything in `appwriter.push` sends to gst’s `appsrc` and gst pipeline in turn does the decode and filesink. Is there a specific place in code where media.Writer is used for VP8?
&gt; Sending NACKs and PLIs on interval is not recommended
AFAIK, sending PLIs on interval is a rough workaround for not handling NACKs. Livekit Server handles the NACKs but do we need to send it the NACK via RTCP for particular packets not received?

• Right, I haven't seen that with VP8, but the solution still holds: we can choose not to push that buffer if it encounters an error
• Yeah I can't seem to find it. Probably will need to check with <@U01UB0LHTTQ> . The reason I said it is because one of the todos is to replace `ivfwriter` which I presume is Pion's implementation
• I don't think we need to. I'll defer to <@U01KZ61GV5Z> for better advice. I tried sending PLI on a 3-second interval in another project and the video quality degraded for all participants in the room, so I wouldn't recommend it

There’s lot here, thanks for all the detail!

• `twirp error internal: no response from egress service` seems related to `redis channel is full`, I’ll need to fix that
• I haven’t seen the `buffer too small` error, do you have a good way to reproduce it? We are not using media.Writer, only gstreamer
• I haven’t seen the `negotiation problem` either, does the track work if you try it again? Or will it give that error every time for a certain track
• For now you’ll need to delete the leftover egress IDs from redis - I’ll update it to not require the room to exist
• NACKs are handled by default by an interceptor
• PLIs are sent when a sample is dropped or when a track is unmuted because it will need the full refresh to display the other frames. Sending a PLI every few seconds isn’t necessary, it just adds more work and congestion

Created some issues for tracking <https://github.com/livekit/egress/issues>

on the PLI issue, the other pion examples perform it because they are not transcoding the incoming streams. With transcoding, it becomes unnecessary to stuff the pipe with keyframes. We can produce as many keyframes as we need in the output stream

Thanks <@U01UB0LHTTQ> <@U01KZ61GV5Z>
• the `buffer too small` I’ve seen regularly. It happens when user starts streaming the canvas as a video and resolution of video changes due to network conditions. Is there any setting I can change to log in more detail?
• I checked the logs for the gstreamer negotiation error. Got the same error over multiple retries for that track
• Manually deleted the old egress ids from redis via `redis-cli`. The command used was `HDEL egress EGRESS_ID1 EGRESS_ID2 ...`

Update: I was debugging the <https://github.com/livekit/egress/issues/26|redis channel issue>. Setting `s.handleRequest()` to `go s.handleRequest()` in <https://github.com/livekit/egress/blob/main/pkg/service/service.go#L111|service.go>  seems to fix the `no response from egress service`error. Wanted to confirm if it is safe to run it in a goroutine?

It is safe to run in a goroutine, it just needs to then deny other requests while it's running room composite egress

<@U030F40L81X> Regarding the negociation error: would it be possible to have some more detail? What is the source? Does it happen immediately when setting up the output or after running some time? Could you also confirm the version of gstreamer? Thanks

<@U03H6MNQ9G9> It happened immediately when setting up the output. I’m using gstreamer v1.18 from livekit-egress container

I believe it's the json file with account keys as you said, I'll have to look into encoding with helm and get back to you with an example

<@U01UB0LHTTQ> wanted to bump this as I'm looking into egress again and still encountering the same unmarshal errors.  Any sample values file for GCP would be really helpful.

Seems to be related to the JSON key, specifically.

ec2 default user does not have write permissions to /opt/ directory. that might be the reason that it is not working there.

have you tried this? <https://docs.livekit.io/deploy/vm/#instance-started-before-networking|https://docs.livekit.io/deploy/vm/#instance-started-before-networking>

this happens with AWS. the commands on that page helps to get through it

It didn’t even create the folder
```bootcmd:
  - mkdir /opt/livekit-server/ssl```