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 73B9246881
	for <ffmpegdev@gitmailbox.com>; Thu, 22 Jun 2023 17:43:22 +0000 (UTC)
Received: from [127.0.1.1] (localhost [127.0.0.1])
	by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8193B68C02E;
	Thu, 22 Jun 2023 20:43:19 +0300 (EEST)
Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net
 [217.70.183.201])
 by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 925C868BF5A
 for <ffmpeg-devel@ffmpeg.org>; Thu, 22 Jun 2023 20:43:13 +0300 (EEST)
X-GND-Sasl: michael@niedermayer.cc
Received: by mail.gandi.net (Postfix) with ESMTPSA id C06B61BF205
 for <ffmpeg-devel@ffmpeg.org>; Thu, 22 Jun 2023 17:43:12 +0000 (UTC)
Date: Thu, 22 Jun 2023 19:43:11 +0200
From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Message-ID: <20230622174311.GE3250409@pb2>
References: <20230622145709.GB3250409@pb2>
 <168745018738.21886.10926077684605560333@lain.khirnov.net>
MIME-Version: 1.0
In-Reply-To: <168745018738.21886.10926077684605560333@lain.khirnov.net>
X-Spam-Flag: yes
X-Spam-Level: ************
X-GND-Spam-Score: 180
X-GND-Status: SPAM
Subject: Re: [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="===============4545123483800096864=="
Errors-To: ffmpeg-devel-bounces@ffmpeg.org
Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org>
Archived-At: <https://master.gitmailbox.com/ffmpegdev/20230622174311.GE3250409@pb2/>
List-Archive: <https://master.gitmailbox.com/ffmpegdev/>
List-Post: <mailto:ffmpegdev@gitmailbox.com>


--===============4545123483800096864==
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="vv4Sf/kQfcwinyKX"
Content-Disposition: inline


--vv4Sf/kQfcwinyKX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 22, 2023 at 06:09:47PM +0200, Anton Khirnov wrote:
> Hi,
> I'm sorry to say, the patch at its current state is quite far from
> something I'd consider acceptable for git master.
>=20
> 1) Given that there are sdr and sdrfile demuxers, it seems to me that
> the transport layer should be split into a protocol rather than be
> inside the demuxer

sdrfile is for debuging and testing

can sdrdemux be split into a protocol and demuxer. Probably yes.
This will make the code more difficult to maintain, more complex and and
maybe slower.
Also keep in mind Soapy has some "zero copy" support that i have not looked
into yet. I doubt that becomes easier if it has to be funnled through an ex=
tra
layer

And other devices do not do that, alsa, oss, video4linux have no seperate
protocol.
and adding a alsafile or v4lfile debug option at least to me does not seem
like a good reason to redesign these with protocols
Or consider a alsa or video4linux fate test that used a file as input
It makes sense for these too to have such file choice


> 2) Threading inside the demuxer, with pthread calls randomly sprinkled
> throughout is particularly ugly and dangerous. Demuxers should not do
> their own threading.

IIRC the only reason why any threading is needed ATM is because the buffers
=66rom soapy are too small with some hardware.

i dont think its fair to call the pthread code randomly sprinkled when
all mutex code is around either fifo calls or the seek direction or wanted =
frequency
fields.
In fact if AVFifo was thread safe half the lock/unlock calls would be gone

Of course in the future we want to do the FFT in 2 or more threads so the
maximum that can be processed is higher (some expensive hw can deliver
alot more data)

But more important than "ugly" is the dangerous bit, can you elaborate
what is dangerous here, especially in relation to how to make it better ?


> 3) sdr_read_header() and sdr_read_packet() are giant, hideous, and
> unreadable.

I disagree that they are hideous and unreadable. In fact its largely just
setting up the hw in sdr_read_header() and thats very close to what the
libsoapy example code does.

But ill see if it can be split a bit.


> 4) Why does there seem to be drawing code in a demuxer?

Because in a practical use case the user needs feedback from what is
available in the radio spectrum. That can be disabled, ill
change this to be disabled by default.

Thx

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire

--vv4Sf/kQfcwinyKX
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZJSIKwAKCRBhHseHBAsP
qxBJAJ9yqb4L4Fx0iN+mdRbWbzSeMnzFuQCeK4+o68ue0Mibbb57q2cCBGGOGSo=
=YtRC
-----END PGP SIGNATURE-----

--vv4Sf/kQfcwinyKX--

--===============4545123483800096864==
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".

--===============4545123483800096864==--