Re: [FFmpeg-devel] What is FFmpeg and what should it be

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 4790 bytes --]

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)
> 
> Did you ask people to do that?
> 
> > How many people say what they want an SDR API to be able to do ? (0)
> 
> > 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
> 
> 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 patches)

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 produces
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 vissible "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 user
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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".