From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ffmpeg-devel-bounces@ffmpeg.org> Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 9A30545781 for <ffmpegdev@gitmailbox.com>; Thu, 22 Jun 2023 14:57:20 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2210268C081; Thu, 22 Jun 2023 17:57:18 +0300 (EEST) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6869668BF6B for <ffmpeg-devel@ffmpeg.org>; Thu, 22 Jun 2023 17:57:11 +0300 (EEST) X-GND-Sasl: michael@niedermayer.cc Received: by mail.gandi.net (Postfix) with ESMTPSA id 5DFEE24000C for <ffmpeg-devel@ffmpeg.org>; Thu, 22 Jun 2023 14:57:10 +0000 (UTC) Date: Thu, 22 Jun 2023 16:57:09 +0200 From: Michael Niedermayer <michael@niedermayer.cc> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Message-ID: <20230622145709.GB3250409@pb2> MIME-Version: 1.0 X-Spam-Flag: yes X-Spam-Level: ************ X-GND-Spam-Score: 180 X-GND-Status: SPAM Subject: [FFmpeg-devel] [RFC] SDR X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org> List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe> List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel> List-Post: <mailto:ffmpeg-devel@ffmpeg.org> List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help> List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe> Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Content-Type: multipart/mixed; boundary="===============1108739164064777282==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> Archived-At: <https://master.gitmailbox.com/ffmpegdev/20230622145709.GB3250409@pb2/> List-Archive: <https://master.gitmailbox.com/ffmpegdev/> List-Post: <mailto:ffmpegdev@gitmailbox.com> --===============1108739164064777282== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oC1+HKm2/end4ao3" Content-Disposition: inline --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all My humble opinion(s) and plan(s) about SDR FFmpeg as a multimedia framework should support SDR. The only practical way to support SDR in FFmpeg ATM is through a demuxer (o= r equivalent) Not everyone is happy about a SDR demuxer. The "active" code could be in the demuxer itself or an external library. I think the 2 important factors for external vs internal are 1. Does it support features beyond what a multimedia framework needs? 2. How many active developers work on it If we support just audio and video (de)modulation it fits nicely in FFmpeg maybe we should consider improving the APIs we have so we have better places than demuxers for functionality like this, but thats a long term goal that requires a team effort or a dedicated volunteer. Its not a bad idea at all = and I certainly am in favor for improving the APIs. OTOH if we support things beyond audio/video, maybe wifi packets, bluetooth and so forth then SDR should be a seperate library. Also this choice is not a constant, we can easily start out inside libavfor= mat and * if sdrdemux grows beyond what makes sense in FFmpeg split it out into an = external libraray * if APIs in FFmpeg evolve so that other places become possible, move it in= to libavfilter or whatever other place fits better What i would suggest is: * get the current code or revission of it into the git master branch as a d= emuxer. * see how many people enjoy working on SDR and how far these people want to= take it * keep an open mind about the future of this code, and move it elsewhere wh= en it makes sense to do so. * ATM i think incubating this SDR stuff in FFmpeg and have it grow makes mo= re sense than having it in a seperate place and a demuxer in FFmpeg depending on t= hat. PS: Also something like plugins would help for things like this. As one cou= ld then maintain code like a sdr-demuxer outside the main repository. So noone who = doesnt like it needs to touch it in any way while users who want it can easily ena= ble it ... Thx --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus --oC1+HKm2/end4ao3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZJRhQQAKCRBhHseHBAsP qyG0AKCZD1MnQKVulku8YFI1Zuj06h3YJACgh1CKfPQ4LPPdiZv8Zi5v9bGllPk= =IwZf -----END PGP SIGNATURE----- --oC1+HKm2/end4ao3-- --===============1108739164064777282== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============1108739164064777282==--