Debian trixie support

[ayufan]

Includes the #184.

[ajn142]

Is the only thing preventing this from being merged the build errors with Bullseye? It looks like that's related to 9df363e requiring libdatachannel 0.23.2, requiring libsrtp 2.7, which requires cmake 3.21, which isn't present in bullseye.

[ajn142]

Is the only thing preventing this from being merged the build errors with Bullseye? It looks like that's related to 9df363e requiring libdatachannel 0.23.2, requiring libsrtp 2.7, which requires cmake 3.21, which isn't present in bullseye.

If I’ve followed that case correctly, would it be sufficient to limit the version pinning of libdatachannel to Bookworm and Trixie, which can support it with make >= 3.21, and allow Bullseye to compile with any old version of libdatachannel, as before?

[mryel00]

In my opinion, Bullseye should not be a blocker and support should just get dropped, if supporting it is a hassle. Best would be a separate branch with a working legacy version.

But currently there is a different blocker. WebRTC is not working. This is due to the removal of sendTime. This results in just the key frames getting shown.

[mryel00]

Do not remove sendTime. If you remove it, WebRTC won't work and the client will only show the keyframes.

[ayufan]

I will look at this early next week and merge relevant updates. Thanks for contributions!

…

On Mon, 13 Oct 2025 at 23:32, Patrick Gehrsitz ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In output/webrtc/webrtc.cc <#185 (comment)> : > @@ -63,23 +62,6 @@ struct ClientTrackData void startStreaming() { - double currentTime_s = get_monotonic_time_us(NULL, NULL)/(1000.0*1000.0); - sender->rtpConfig->setStartTime(currentTime_s, rtc::RtpPacketizationConfig::EpochStart::T1970); - sender->startRecording(); - } - - void sendTime() Do not remove sendTime. If you remove it, WebRTC won't work and the client will only show the keyframes. — Reply to this email directly, view it on GitHub <#185 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASOSQIFGB2MDCKVUWZV7ED3XQK6JAVCNFSM6AAAAACDCGPAWKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTGMZTGA4DMMJXHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mryel00]

We just found another issue. Chromium based browsers and the OrcaSlicer Browser (no idea what that's based on), cannot connect to the WebRTC stream. Firefox based browsers work without problem.

The error I get, after applying this fix I mentioned above, is as follows:

Unchecked runtime.lastError: The message port closed before a response was received.
webrtc:129 OperationError: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to parse SessionDescription. a=msid: video Missing stream ID in msid attribute.
    at webrtc:109:21

Without this PR applied it's still working on Bookworm. The problem exists on Bookworm and Trixie.

[mryel00]

As you can see in the Mainsail PR mainsail-crew/mainsail#2276, a fix is rather simple and you just need to explicitly set the stream ID to a non empty string.

We have no idea why this happens just with the newer libdatachannel version, as e.g. the master and main branch work without problems, and it's just this PR breaking it with an empty string.

edit: To be specific, each time you call webrtc_add_video, you currently set the last argument to "". Replacing it by "stream" should fix the error.