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 7EE9246AE2 for ; Thu, 3 Aug 2023 17:45:17 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 987F268C693; Thu, 3 Aug 2023 20:45:13 +0300 (EEST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8E8AF68C1A9 for ; Thu, 3 Aug 2023 20:45:06 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id E04596000F for ; Thu, 3 Aug 2023 17:45:05 +0000 (UTC) Date: Thu, 3 Aug 2023 19:45:05 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230803174505.GN7802@pb2> References: <20230802125521.GG7802@pb2> <20230802142026.GI7802@pb2> <61649ed7-f0d3-4f16-8e68-c8e258e96aaa@betaapp.fastmail.com> MIME-Version: 1.0 In-Reply-To: <61649ed7-f0d3-4f16-8e68-c8e258e96aaa@betaapp.fastmail.com> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] What is FFmpeg and what should it be 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="===============7868421337482790755==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============7868421337482790755== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8aXdbsI7WZXWoJi3" Content-Disposition: inline --8aXdbsI7WZXWoJi3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 02, 2023 at 04:44:14PM +0200, Jean-Baptiste Kempf wrote: > On Wed, 2 Aug 2023, at 16:20, Michael Niedermayer wrote: > > There are multiple problems but the real problem is that > > How many people discuss an SDR API ? (0) > > How many people propose an SDR API ? (0) >=20 > Did you ask people to do that? >=20 > > How many people say what they want an SDR API to be able to do ? (0) >=20 > > Again we had 0 that is ZERO discussions about an SDR API. > > where does it start ? a hw enumerate, a soapy device, a void * > > representing a SDR data stream from something like soapy >=20 > Just enough to integrate into AVInputFormat and libavformat + libavdevice. > Propose something and you will get more feedback well, i did with all the patches i posted over the last 2 months and what we now have in the libavradio repository (which equals these patch= es) Theres libsoapy (100% external to us) which gives us device enumeration, option enumeration and a path from a opened device to a "IQ" stream of "radio frequency" samples that is interfaced with by a AVInputFormat demuxer / input format and produ= ces AVPackets (raw audio and in the future for DAB, mp2 & AAC) I have proposed 2 choices here 1. have this API in a separate library (libavradio) 2. have it in libavdevice like other input devices The only comment i remember was that MPEG-TS would cause problems (i think multiple people mentioned that) The rest of this mail thus talks only about the MPEG-TS case because no other issue with using the existing API was raised. There are 2 things DAB and DVB both use mpeg ts if i implement DAB fully without external libs, i can treat mpeg-ts like the previous layers of modulations and error correction and just remove it. (I probably will wakeup with a stake through my heart surrounded by some broadcast guild) but theres no technical issue here if OTOH i implement DAB through an external lib we get AAC frames and never even see the MPEG-TS (that at least according to the documentation i read). So these do teh same thing, they drop MPEG-TS as soon as possible. DAB thus has no MPEG-TS related issue Now DVB (if i understand everything correctly) the most popular SDR device AFAIK are the cheap RTLSDR sticks they support DVB only thorugh a seperate hardware path and not in SDR mode. The bandwidth in SDR mode is not big enough for DVB. What this means is the majority of people will either use such a stick in "DVB" mode for DVB which provides mpeg-ts from the kernel and no vissibl= e "SDR" or in "SDR" mode with no DVB so no question about mpeg-ts either To really hit a problem with mpeg-ts we first needs a SDR device capable to return the needed bandwidth (thats not the cheapest solution for the end us= er so I question a bit how many users we have here) then we would need to write a implementation of DVB demodulation (noone plans to implement that AFAIK, i certainly dont plan to) and then we would have a MPEG-TS stream with probably multiple programs and multiple audio and video streams in it and that depending on what parts are being demodulated. We have other demuxers which handle MPEG-TS internally. So it can still be done, if needed To me the obvious solution here is just to not support DVB if people want MPEG-TS from DVB * It wont work with the cheap sticks * It would be alot of work to implement the DVB demodulation * It doesnt fit very nicely in the architecture and a architecture in which it fits will be messy and complex * The kernel has a interface for it already AFAIK and here we end, where we started, with my simple minded demuxer and input device either in libavradio lib or in libavdevice&libavformat. If someone wants to do DVB in the future she would have to change the architecture or accept that no MPEG-TS will come out but theres no "old API" that has to go through a deprecation cycle as its just the AVInputFormat stuff. Are people suggesting we design a new API around MPEG-TS even though noone will implement anything that returns MPEG-TS and has no plans to implement = that even in the distant future ? It seems a strange design goal to me and iam not even sure thats what people ask for? To me the input device API is covering everything you can do with this If someone wants a different intermediate API, send a patch, i just dont understand the issue that is supposed to fix. It seems a bit like "hate" for the input device API, as in "i want to use it but i sweared an oath not to use libavdevice APIs" thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato=20 --8aXdbsI7WZXWoJi3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZMvnnQAKCRBhHseHBAsP q7RmAJwLuB0TGxVQknxYuZIV/+x8lF6cUACgmHbzl5QUXCLRQSMbFlCC2BTEwLI= =c4+P -----END PGP SIGNATURE----- --8aXdbsI7WZXWoJi3-- --===============7868421337482790755== 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". --===============7868421337482790755==--