DJMAKEITBRAIN
Explore posts from serversSMSoftware Mansion
•Created by DJMAKEITBRAIN on 8/29/2024 in #membrane-help
WebRTC TURN TCP/TLS configuration issue
Sorry for the long delay - getting a ton of logs on the server side, but I'm not sure what to look for. I'm not seeing anything pertinent
4 replies
SMSoftware Mansion
•Created by DJMAKEITBRAIN on 4/28/2023 in #membrane-help
Membrane.Source example for RTC Engine
I dunno if this helps, but here's our handle_pad_added:
15 replies
SMSoftware Mansion
•Created by DJMAKEITBRAIN on 4/28/2023 in #membrane-help
Membrane.Source example for RTC Engine
My best guess is that the following is happening:
1. The API we're calling for the audio responds with a stream of chunks.
2. Those chunks are received very quickly (faster than the duration of the audio they contain), and we process them as they arrive.
3. We package these chunks into an RTP stream via Membrane.RTP.PayloaderBin.
4. Membrane forwards these packets to the client as soon as they arrive.
5. Because they're received by the client faster than it can play them back, it starts dropping packets. (see section 3.2 of https://www.rfc-editor.org/rfc/rfc7002)
So...do we need to control the rate of playback on the Membrane side in order to make this work? I guess I assumed it would measure things out on its own.
15 replies
SMSoftware Mansion
•Created by DJMAKEITBRAIN on 4/28/2023 in #membrane-help
Membrane.Source example for RTC Engine
Interesting, thanks! We're seeing no packets lost, but the majority of packets are discarded. That might speak to a timestamp issue...do you know how that might come about, and what we could do about it?
Membrane Videoroom sounded just fine with two tabs!
15 replies
SMSoftware Mansion
•Created by DJMAKEITBRAIN on 4/28/2023 in #membrane-help
Membrane.Source example for RTC Engine
@mickel8. Yep, that's mostly correct. I've made my own Source, similar to Hackney, but actually forwarding a stream of audio chunks from successive API calls.
I've added that endpoint to the engine, and that track is being listened to by 2 endpoints:
1. The WebRTC endpoint from the user
2. A recording endpoint that writes the audio to disk.
The recording endpoint records the audio just fine, it sounds exactly as it should. However, the WebRTC endpoint (or at least the audio element in the browser) receives the audio all messed up, missing large sections of it and generally sped up.
Do you know why that might happen? I don't think the issue is with my Source/source endpoint, given that the recorder picks it up fine. The issue must either lie somewhere inside the WebRTC endpoint, or in the browser, I'd imagine. Any help would be much appreciated!
15 replies