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 DA4AD469F9 for ; Sat, 1 Jul 2023 21:25:53 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id F038C68C194; Sun, 2 Jul 2023 00:25:50 +0300 (EEST) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 66DC668BFB7 for ; Sun, 2 Jul 2023 00:25:44 +0300 (EEST) X-GND-Sasl: michael@niedermayer.cc Received: by mail.gandi.net (Postfix) with ESMTPSA id B2B17FF803 for ; Sat, 1 Jul 2023 21:25:43 +0000 (UTC) Date: Sat, 1 Jul 2023 23:25:42 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230701212542.GI1093384@pb2> References: <20230628212504.2522567-1-michael@niedermayer.cc> <20230630140838.GA1093384@pb2> <4f0dc1-fb9b-a532-05a-6e8e1debfe91@martin.st> <20230701144442.GD1093384@pb2> <2e90ba71-f56f-974d-d76d-a750c480c09c@martin.st> <20230701200635.GH1093384@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio 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: multipart/mixed; boundary="===============1296282639171576958==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============1296282639171576958== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2xeD/fx0+7k8I/QN" Content-Disposition: inline --2xeD/fx0+7k8I/QN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 01, 2023 at 09:42:14PM +0100, Kieran Kunhya wrote: [...] > > If so, what design ? > > >=20 > This is purely a flaw in FFmpeg that protocol/demux are joined up into the > same library. Also an assumption (coming from things like AVI and probably > reasonable at the time) that there is only going to be one layer of demux, > whereas in modern codecs (HEIF, LC-EVC, Dolby E etc) there can be many > layers of demux required. >=20 > Your logic is flawed, you base your assumption that everyone else is wrong > when it's in fact FFmpeg that's in the wrong by mixing transport and > container into the same library. Iam not assuming anyone is wrong. "wrong" and "right" depend alot on assumtations and point of view. You can be wrong in mathematics. With software you can be wrong if the code doesnt work. Or if code maintaince costs more than the competitor has to pay for the same. if libavformats design is a problem for modern containers it needs to evolve In respect to SDR and multimedia, it seems again not different from the other "many layers of demux" already needed. we even have avpriv_mpegts* as exported functions already ... people may hate libavformats design. Ok but this design doesnt have a problem with the SDR code theres nothing i had to change in libavformats APIs. If theres mpegts id try to pass it throught the existing avpriv_mpegts* code. maybe that would not work and need some amendment, but thats not a big deal >=20 >=20 > > > As for purely AM/FM, I'm not quire sure what the right level for > > > that is though. > > > > > > > > In any case, I disagree with the procedure of stating to push the pat= ch > > if > > > there's no objections, when there has been numerous objections from > > > essentially most of the active community already. > > > > The objections have been unclear, are they against SDR, against the > > implementation. > > I took the liberty to be pushy here to get this more clear. And i will > > continue to do this until i get clear responses. Because otherwise > > iam just stuck as i dont know how to correct the design and code. > > >=20 > They are against SDR as this violates layering. FFmpeg doesn't handle the > physical layer, third party libs do upstream (e.g hardware capture). > Again, should we implement WiFi SDR in FFmpeg? Should we implement a > userspace TCP stack? Should we implement bitbanged Ethernet? All of these > things sit at a different layer to the data and transport layer that FFmp= eg > sits in. You can design something starting with a filter and then define everything a subclass of filter. you can design things with no common class and everything different types. But whatever you call the class for the SDR code and the class of the common demuxers. Their do look very darn similar they should IMHO have a common parent class. Call one Demuxer and one Transport but they still do take one input stream (a stream of complex values in case of SDR) and spit out multiple streams raw audio, raw video, mpegts. And same way (other) demuxers also can return raw audio, raw video, mpegts thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Homeopathy is like voting while filling the ballot out with transparent ink. Sometimes the outcome one wanted occurs. Rarely its worse than filling out a ballot properly. --2xeD/fx0+7k8I/QN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZKCZ0QAKCRBhHseHBAsP qwuGAJ9BZalh8v6Q7boTlxEm+L/5oOYoIQCfSgxPrfgskflCEZhZkpSjcmRb/LY= =gD1b -----END PGP SIGNATURE----- --2xeD/fx0+7k8I/QN-- --===============1296282639171576958== 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". --===============1296282639171576958==--