https://livekit.io logo
Join Slack
Powered by
This message was deleted.
# helpdesk
s
This message was deleted.
n
https://github.com/livekit-examples/livestream/ This is the demo/example I'm referring to. Thus far, I have tried editing the src/server/api/routers/ingress.ts file to change the input to WHIP, and also adding the "bypassTranscoding = true" option. It successfully sends me a valid WHIP link to stream to, but this has not led to any difference in delay. I am streaming via OBS and have tried different encoder settings such as x264 and NVENC with "zerodelay" and "ultra low latency" respectively, with no difference as well. Any help would be appreciated.
a
just to make sure I understand, you’re running LiveKit Ingress on a VPS and seeing a ~5sec delay on ingestion, and the same OBS publisher configuration gets you subsecond latency on other WHIP/RTMP ingestion implementations?
n
Yes, that's accurate.
a
got it. I’ll ask the ingress engineers if they have any ideas. In the meantime, do you mind if I ask what other ingest implementations are working well for you?
n
I have tried this MediaMTX server https://github.com/bluenviron/mediamtx but it had around a ~1 second delay. I have also tried https://github.com/ossrs/srs which worked with almost no delay whatsoever.
a
actually in a couple of weeks we’re going to make a new release of ingress with a bunch of fixes; some of them will probably reduce your latency here in the meantime, what version of everything (livekit, ingress, etc) are you running?
n
the :latest release docker images
d
By default, Ingress transcodes during ingestion to enable simulcast. This is to produce adaptive streams that can be consumed by any client. You can disable transcoding with WHIP ingest, docs on it here: https://docs.livekit.io/egress-ingress/ingress/overview/#bypass-transcoding-for-whip-sessions Though even with transcoding, the added latency should be much lower than 5s. that sounds excessive. If this is reproducible, could you provide more details on your setup? (resolution and bitrate of the streams, server configuration, etc)
a
( @dry-elephant-14928 above he noted he set bypassTranscoding: true)
👍 1
n
I tried using the default settings in the livestreaming example, which was the video preset 1080p 30fps 3 layers. I also tried 1080p 30fps 1 layer. I'm using this image specifically https://hub.docker.com/r/livekit/generate
d
something is definitely off here.. with bypassing transcoding, there isn't anything that would add latency.. except for the jitter buffer on the Ingress instances.
how is your networking to the server?
n
My connection to the server doesn't seem to have any problems. OBS streams ~2000-3500kbps with no dropped frames or anything. I can only assume at this point that there's a problem with the demo application? It does give me a WHIP streaming link when I change the settings so I can only assume the changes I make to the code are actually having an effect.
I should also mention that I have used the "Meet" demo on the same server and it had no delay, but low framerate. It's not suitable in my case though because I want to stream through OBS, not through the browser.
Ok. I did some more extensive testing with the livestream example and found the following: 1. Streaming with the default settings (RTMP) I get around ~2s of delay. 2. Changing to WHIP, the delay becomes around ~*7s*. The "bypassTranscoding: true" option seems to have no effect whatsoever. I have attached a screenshot of my current OBS settings (changing "Max B-frames" to 0 has no effect either). Here is the section from 
src/server/api/routers/ingress.ts
that I'm modifying.
Copy code
.mutation(async ({ input, ctx }) => {
 22       const { ingressClient } = ctx;
 23
 24       const ingress = await ingressClient.createIngress(
 25         IngressInput.WHIP_INPUT,
 26         {
 27           name: input.roomSlug,
 28           roomName: input.roomSlug,
 29           participantName: input.streamerName,
 30           participantIdentity: input.roomSlug,
 31           bypassTranscording: true,
 32           video: {
 33             source: TrackSource.CAMERA,
 34             preset: IngressVideoEncodingPreset.H264_1080P_30FPS_1_LAYER,
 35           },
 36           audio: {
 37             source: TrackSource.MICROPHONE,
 38             preset: IngressAudioEncodingPreset.OPUS_STEREO_96KBPS,
 39           },
 40         }
 41       );
 42
 43       return ingress;
 44     }),
d
Thanks for the detailed notes @numerous-sundown-7970. CC: @chilly-animal-65189 re latency with WHIP. that's def unexpected. Which version of OBS are you running? I have v30-beta3 and see different encoder options. Can you give the following a try?
n
Hello @dry-elephant-14928. Thank you for the reply. I'm also using OBS 30.0.0-beta3. I have recreated your settings and I'm getting around ~3 seconds of delay using both WHIP and RTMP. Edit: Going back to my previous settings (attached in previous comment) the delay goes back to around ~7-8s on WHIP.
c
Upcoming version of ingress may improve things wrt larency with large key frame intervals. At the cost of longer time before video appears on the client if transcoding is bypassed.
n
But from what I understand, it should already deliver sub-second latency, no?
d
@numerous-sundown-7970 WHIP + skip-transcode should give you sub-second latency. Otherwise, there will be a bit of latency introduced by the fact that there are two passes of transcode taking place. Just to be sure, what do you mean by "delay"? is it the amount of time before the first frame is rendered on the receiving side? or the amount of time that the remote display lags what's happening on the publisher side? The former is more related to keyframe interval, where as the latter is what I mean by stream latency
n
@dry-elephant-14928 Sorry for the late reply, I haven't checked Slack in a while. I mean once the stream is loaded and everything, the delay between what happens on my screen (as the streamer) and what I see on the stream. So if I move my mouse to the right, it would take about 3 seconds (or 7-8 seconds in the scenarios described above) to see that change on the stream. Letting the stream run for 5 or even 10 minutes does not reduce this delay.
d
No problem, thanks for confirming it's latency. Your initial settings aren't optimized for real-time content.. so it wouldn't matter when we've received it. We'll take a look at WHIP with bypass transcode. I think it should be possible to lower latency to <1s. we have not spent much time optimizing for that use case since for real-world scenarios, you'd really want simulcast.
2 Views
Open in Slack
PreviousNext
Powered by