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==--