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 73B9246881 for ; 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 ; 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 ; Thu, 22 Jun 2023 17:43:12 +0000 (UTC) Date: Thu, 22 Jun 2023 19:43:11 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============4545123483800096864==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============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==--