From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=crans.org (client-ip=185.230.79.39; helo=redisdead.crans.org; envelope-from=erdnaxe@crans.org; receiver=) Authentication-Results: mail.toke.dk; dkim=pass (4096-bit key) header.d=crans.org header.i=@crans.org header.b=H2HZx157 Received: from redisdead.crans.org (redisdead.crans.org [185.230.79.39]) by mail.toke.dk (Postfix) with ESMTPS id 00BBF826FC9 for ; Tue, 6 Apr 2021 19:44:09 +0200 (CEST) Received: from [192.168.1.204] (ip-213-124-167-106.ip.prioritytelecom.net [213.124.167.106]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by redisdead.crans.org (Postfix) with ESMTPSA id DC2E87FC; Tue, 6 Apr 2021 19:44:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crans.org; s=mail; t=1617731047; bh=LEzz7MJoLJwJELimQ/0yJVSfS2RhgxfNY39VGCs6Nv8=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=H2HZx157d9qeyVb4h0qNsndrwfwuq7+Si7ONlTqWL3OM13ZEY/8T7UeJTgdNaAZtC sz+WN6iCcWRBuF/Q9XLriqCQhpF+Zi6G5vveCqk8TfwS1cOn2FfuEOoJfzT+hKEm1c r0SykFmPpxDXLhNUXb0ho/rwpfLwUKolNCJDkc0FZAy+5nS8rgT3y8Yu1inzlYoQCM i1QJVpwv2x9akj12jwHDEDzrfUYhGnuhGzGK7emlcOubMw3D+V2FMq2k9DgJP30YZe /k8tx1daWGybOvep/t9TuZXj63Q8OllUnmhf1CMkTeTW7tysLVDHGYvF1HWTEahuWz ufQgvtthvLg84CsJxSPViOjC9FXbpVUKoe3UJifVf0OKjQA/THuSoDBYCuy00z77nY RGapBSzUPTq47SFZw8fK8AZoqVmC9m6RuHTZw2nMlVGRKizr1J+IhJIXSaBZL8B+po wnGBqjtWIGb+/km2O4D2jPzq1/xGLXIaLlN7CEQbcXI/+uGlmZ/CfPB+2TSCeGQZtQ NhPfg/qwcTfJE0eMNVApsn21AgMV6DwVI7KzPIzWI2efYckqTlCOOPf0gXisPRZmEQ UwU51Il8A+oEEr+1HZHxOqfgQUIIkMVWfNXZxHYg/iyNP+Jfjhal1ZBt6WX9ZEo4ow zE28mGBcTvFn2DMTmZpyQhds= To: Juliusz Chroboczek References: <228e92c1-d1f7-bc6d-4f44-c9cfd28f0096@crans.org> <87zgybsh84.wl-jch@irif.fr> From: Alexandre IOOSS Organization: Crans Message-ID: <76e5b62b-ee5b-3117-ea04-368fab0e659b@crans.org> Date: Tue, 6 Apr 2021 19:44:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <87zgybsh84.wl-jch@irif.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Message-ID-Hash: F5VS44DAJIFWCVUJJYZP2MX2NZZBH2RS X-Message-ID-Hash: F5VS44DAJIFWCVUJJYZP2MX2NZZBH2RS X-MailFrom: erdnaxe@crans.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: galene@lists.galene.org X-Mailman-Version: 3.3.4 Precedence: list Subject: [Galene] =?utf-8?q?Re=3A_Building_a_streaming_gateway_for_Gal=C3=A8ne?= List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 4/6/21 2:57 PM, Juliusz Chroboczek wrote: > I'll have a look at your code as soon as I have some time. In the > meantime, there are three things that you need to do: > > 1. send periodic RTCP Sender Reports with accurate NTP times; > 2. react to RTCP PLI packets by inserting a keyframe; > 3. react to RTCP NACK packets by resending the packets listed in the NACK. > > (1) is essential for proper lipsynch. (2) is what allows a stream to > recover after a catastrophic loss event. (3) is what allows a stream to > recover rapidly after moderate amounts of loss. When dumping traffic in Wireshark, I see only RTCP "Sender report" and "Receiver report" packets. Sender reports are periodic, and sent by groups of 2 (video then audio): ``` Real-time Transport Control Protocol (Sender Report) 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0000 = Reception report count: 0 Packet type: Sender Report (200) Length: 6 (28 bytes) Sender SSRC: 0x9ce1015b (2631991643) Timestamp, MSW: 2797058655 (0xa6b7ba5f) Timestamp, LSW: 1448315617 (0x56538ae1) [MSW and LSW as NTP timestamp: Aug 20, 1988 08:44:15.337212257 UTC] RTP timestamp: 866227088 Sender's packet count: 2194185357 Sender's octet count: 2612991028 [RTCP frame length check: OK - 28 bytes] Real-time Transport Control Protocol (Sender Report) 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0000 = Reception report count: 0 Packet type: Sender Report (200) Length: 6 (28 bytes) Sender SSRC: 0x3a724a90 (980568720) Timestamp, MSW: 4079490799 (0xf32816ef) Timestamp, LSW: 2870575121 (0xab198011) [MSW and LSW as NTP timestamp: Apr 10, 2029 07:53:19.668357853 UTC] RTP timestamp: 2166723788 Sender's packet count: 468654353 Sender's octet count: 2838781192 [RTCP frame length check: OK - 28 bytes] ``` I don't really understand what you mean by "accurate NTP times". Streams from Firefox or GStreamer seem to use random NTP timestamps. When dumping Firefox WebRTC traffic, I also see "Generic RTP Feeback: NACK" packets, which confirms the fact that GStreamer is not doing NACK in my script. I should see if it's possible to enable it. I am still quite new to WebRTC, so be aware that I might have done something stupid with the GStreamer pipeline. Thank you for pointing out this could be a potential problem, -- Alexandre Iooss