From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 1DEE74762C for ; Tue, 14 Nov 2023 15:46:25 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 993BC68CD42; Tue, 14 Nov 2023 17:46:22 +0200 (EET) Received: from glom.nmugroup.com (glom.nmugroup.com [193.183.80.6]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6AF9E68CBA8 for ; Tue, 14 Nov 2023 17:46:16 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by glom.nmugroup.com (Postfix) with ESMTP id DF7B854296BE for ; Tue, 14 Nov 2023 16:46:15 +0100 (CET) Received: from debian.lan (unknown [IPv6:2a00:66c0:a::72c]) (Authenticated sender: git01) by glom.nmugroup.com (Postfix) with ESMTPSA id 9FB7454296BD for ; Tue, 14 Nov 2023 16:46:15 +0100 (CET) Message-ID: From: Tomas =?ISO-8859-1?Q?H=E4rdin?= To: FFmpeg development discussions and patches Date: Tue, 14 Nov 2023 16:46:01 +0100 In-Reply-To: <2638aec6-49ff-4714-8158-9de42bd9c69a@nativewaves.com> References: <0f21e4f846a1190521896ed7f3a23ffc8993589a.camel@haerdin.se> <2638aec6-49ff-4714-8158-9de42bd9c69a@nativewaves.com> User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH v2 0/6] WebRTC sub-second live streaming support X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: tis 2023-11-14 klockan 13:59 +0100 skrev Michael Riedl: > Another option is an external project for WebRTC testing, but the > challenge is > keeping it maintained and compatible with changes in implementations. Perhaps there are funds to raise for such an effort? I can imagine Google et al have an interest in this. > External services might update their software, causing issues with > tests. We > would need a plan for dealing with that. Just making sure various free software implementations interoperate would be more than enough work, and provides some confidence. Surveying what features are supported by each implementation would also be of interest I imagine. For example a client of mine uses aiortc which is lacking FEC and rate control. A local company that sometimes contributes to FFmpeg is also involved in various streaming stuff (though not WebRTC so far, I think). > For paid services like Millicast, we need to figure out who pays for > the tests. > Understanding the costs is essential if we want to use paid services > for > testing. > > I'd like to hear your thoughts on these points and how you would > propose to > proceed with adding tests for protocols like WebRTC. The way I've been testing this stuff so far is by hand via Firefox and Chromium. Both can be automated, though frontend isn't really my area. As it stands at the moment, we let users be guinea pigs for our protocols. While not great, this at least means we get bug reports. But there's no way to ensure old bugs don't resurface. /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".