[FFmpeg-devel] [RFC] SDR

[FFmpeg-devel] [RFC] SDR

[Michael Niedermayer]

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

Hi all

My humble opinion(s) and plan(s) about SDR

FFmpeg as a multimedia framework should support SDR.

The only practical way to support SDR in FFmpeg ATM is through a demuxer (or equivalent)
Not everyone is happy about a SDR demuxer.

The "active" code could be in the demuxer itself or an external library.

I think the 2 important factors for external vs internal are
1. Does it support features beyond what a multimedia framework needs?
2. How many active developers work on it

If we support just audio and video (de)modulation it fits nicely in FFmpeg
maybe we should consider improving the APIs we have so we have better places
than demuxers for functionality like this, but thats a long term goal that
requires a team effort or a dedicated volunteer. Its not a bad idea at all and
I certainly am in favor for improving the APIs.

OTOH if we support things beyond audio/video, maybe wifi packets, bluetooth
and so forth then SDR should be a seperate library.

Also this choice is not a constant, we can easily start out inside libavformat
and
* if sdrdemux grows beyond what makes sense in FFmpeg split it out into an external
  libraray
* if APIs in FFmpeg evolve so that other places become possible, move it into
  libavfilter or whatever other place fits better

What i would suggest is:
* get the current code or revission of it into the git master branch as a demuxer.
* see how many people enjoy working on SDR and how far these people want to take it
* keep an open mind about the future of this code, and move it elsewhere when it
  makes sense to do so.
* ATM i think incubating this SDR stuff in FFmpeg and have it grow makes more sense
  than having it in a seperate place and a demuxer in FFmpeg depending on that.

PS: Also something like plugins would help for things like this. As one could then
maintain code like a sdr-demuxer outside the main repository. So noone who doesnt
like it needs to touch it in any way while users who want it can easily enable
it ...

Thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus

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

Re: [FFmpeg-devel] [RFC] SDR

[James Almer]

On 6/22/2023 11:57 AM, Michael Niedermayer wrote:
> Hi all
> 
> My humble opinion(s) and plan(s) about SDR
> 
> FFmpeg as a multimedia framework should support SDR.
> 
> The only practical way to support SDR in FFmpeg ATM is through a demuxer (or equivalent)
> Not everyone is happy about a SDR demuxer.
> 
> The "active" code could be in the demuxer itself or an external library.
> 
> I think the 2 important factors for external vs internal are
> 1. Does it support features beyond what a multimedia framework needs?
> 2. How many active developers work on it
> 
> If we support just audio and video (de)modulation it fits nicely in FFmpeg
> maybe we should consider improving the APIs we have so we have better places
> than demuxers for functionality like this, but thats a long term goal that
> requires a team effort or a dedicated volunteer. Its not a bad idea at all and
> I certainly am in favor for improving the APIs.
> 
> OTOH if we support things beyond audio/video, maybe wifi packets, bluetooth
> and so forth then SDR should be a seperate library.
> 
> Also this choice is not a constant, we can easily start out inside libavformat
> and
> * if sdrdemux grows beyond what makes sense in FFmpeg split it out into an external
>    libraray
> * if APIs in FFmpeg evolve so that other places become possible, move it into
>    libavfilter or whatever other place fits better
> 
> What i would suggest is:
> * get the current code or revission of it into the git master branch as a demuxer.
> * see how many people enjoy working on SDR and how far these people want to take it
> * keep an open mind about the future of this code, and move it elsewhere when it
>    makes sense to do so.
> * ATM i think incubating this SDR stuff in FFmpeg and have it grow makes more sense
>    than having it in a seperate place and a demuxer in FFmpeg depending on that.
> 
> PS: Also something like plugins would help for things like this. As one could then
> maintain code like a sdr-demuxer outside the main repository. So noone who doesnt
> like it needs to touch it in any way while users who want it can easily enable
> it ...
> 
> Thx

Add it as an input device in lavd, since it's after all a capture 
device. Share the common code with the "file" demuxer in lavf using 
avpriv, since lavd and lavf are completely intertwined.

Just my 2 cents.
_______________________________________________
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".

Re: [FFmpeg-devel] [RFC] SDR

[Thilo Borgmann]

Am 22.06.23 um 17:01 schrieb James Almer:
> On 6/22/2023 11:57 AM, Michael Niedermayer wrote:
>> Hi all
>>
>> My humble opinion(s) and plan(s) about SDR
>>
>> FFmpeg as a multimedia framework should support SDR.
>>
>> The only practical way to support SDR in FFmpeg ATM is through a demuxer (or equivalent)
>> Not everyone is happy about a SDR demuxer.
>>
>> The "active" code could be in the demuxer itself or an external library.
>>
>> I think the 2 important factors for external vs internal are
>> 1. Does it support features beyond what a multimedia framework needs?
>> 2. How many active developers work on it
>>
>> If we support just audio and video (de)modulation it fits nicely in FFmpeg
>> maybe we should consider improving the APIs we have so we have better places
>> than demuxers for functionality like this, but thats a long term goal that
>> requires a team effort or a dedicated volunteer. Its not a bad idea at all and
>> I certainly am in favor for improving the APIs.
>>
>> OTOH if we support things beyond audio/video, maybe wifi packets, bluetooth
>> and so forth then SDR should be a seperate library.
>>
>> Also this choice is not a constant, we can easily start out inside libavformat
>> and
>> * if sdrdemux grows beyond what makes sense in FFmpeg split it out into an external
>>    libraray
>> * if APIs in FFmpeg evolve so that other places become possible, move it into
>>    libavfilter or whatever other place fits better
>>
>> What i would suggest is:
>> * get the current code or revission of it into the git master branch as a demuxer.
>> * see how many people enjoy working on SDR and how far these people want to take it
>> * keep an open mind about the future of this code, and move it elsewhere when it
>>    makes sense to do so.
>> * ATM i think incubating this SDR stuff in FFmpeg and have it grow makes more sense
>>    than having it in a seperate place and a demuxer in FFmpeg depending on that.
>>
>> PS: Also something like plugins would help for things like this. As one could then
>> maintain code like a sdr-demuxer outside the main repository. So noone who doesnt
>> like it needs to touch it in any way while users who want it can easily enable
>> it ...
>>
>> Thx
> 
> Add it as an input device in lavd, since it's after all a capture device. Share the common code with the "file" demuxer in lavf using avpriv, since lavd and lavf are completely intertwined.
> 
> Just my 2 cents.

I'd like it and prefer to have SDR natively in FFmpeg. I also think it makes sense to consider it an lavd device, like James.

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

Re: [FFmpeg-devel] [RFC] SDR

[Anton Khirnov]

Hi,
I'm sorry to say, the patch at its current state is quite far from
something I'd consider acceptable for git master.

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
2) Threading inside the demuxer, with pthread calls randomly sprinkled
throughout is particularly ugly and dangerous. Demuxers should not do
their own threading.
3) sdr_read_header() and sdr_read_packet() are giant, hideous, and
unreadable.
4) Why does there seem to be drawing code in a demuxer?

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

Re: [FFmpeg-devel] [RFC] SDR

[Michael Niedermayer]

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

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.
> 
> 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 extra
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
from 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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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

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

Re: [FFmpeg-devel] [RFC] SDR

[Michael Niedermayer]

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

On Thu, Jun 22, 2023 at 07:43:11PM +0200, Michael Niedermayer wrote:
> On Thu, Jun 22, 2023 at 06:09:47PM +0200, Anton Khirnov wrote:
[...]
> > 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.

Ill include some cleanup, comments and factorization in V3.
Please give me feedback if that is what you had in mind or if it was
something else

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu

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

Re: [FFmpeg-devel] [RFC] SDR

[James Almer]

On 6/22/2023 1:09 PM, 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.
> 
> 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

I disagree. It's not a protocol. I can't get a Matroska bitstream out of 
this like i could from an actual protocol like http, smb, etc. This is a 
capture device.

> 2) Threading inside the demuxer, with pthread calls randomly sprinkled
> throughout is particularly ugly and dangerous. Demuxers should not do
> their own threading.
> 3) sdr_read_header() and sdr_read_packet() are giant, hideous, and
> unreadable.
> 4) Why does there seem to be drawing code in a demuxer?
_______________________________________________
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".

Re: [FFmpeg-devel] [RFC] SDR

[Tomas Härdin]

tor 2023-06-22 klockan 16:57 +0200 skrev Michael Niedermayer:
> If we support just audio and video (de)modulation it fits nicely in FFmpeg

You have no idea what you are getting into. Are we going to implement a
DVB-T demuxer in this project? For what purpose? You can just as well
implement a modem externally that pipes bits into the mpegts demuxer.

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

Re: [FFmpeg-devel] [RFC] SDR

[Tomas Härdin]

fre 2023-06-23 klockan 22:18 +0200 skrev Tomas Härdin:
> tor 2023-06-22 klockan 16:57 +0200 skrev Michael Niedermayer:
> > If we support just audio and video (de)modulation it fits nicely in
> > FFmpeg
> 
> You have no idea what you are getting into. Are we going to implement
> a
> DVB-T demuxer in this project? For what purpose? You can just as well
> implement a modem externally that pipes bits into the mpegts demuxer.

Herp, I obviously mean a DVB-T *modem*

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

Re: [FFmpeg-devel] [RFC] SDR

[Michael Niedermayer]

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

On Fri, Jun 23, 2023 at 10:19:37PM +0200, Tomas Härdin wrote:
> fre 2023-06-23 klockan 22:18 +0200 skrev Tomas Härdin:
> > tor 2023-06-22 klockan 16:57 +0200 skrev Michael Niedermayer:
> > > If we support just audio and video (de)modulation it fits nicely in
> > > FFmpeg
> > 
> > You have no idea what you are getting into. Are we going to implement
> > a
> > DVB-T demuxer in this project? For what purpose? You can just as well
> > implement a modem externally that pipes bits into the mpegts demuxer.
> 
> Herp, I obviously mean a DVB-T *modem*

as said previously i did a AM demodulator, one classical implementation
and one that demodulates it synchronously mapping in phase and quadrature
to mid and side channels or just mono
The idea of the mid and side channels is that if theres 1 transmitter its
mono, if there are 2 transmitters they will appear to come from different
directions as one listens

And i plan to do FM demodulation.

after that i likely have many other non SDR things i want to work on
and would very much be happy to then find someone else working on DAB/DVB
but if noone does and i find time i might look at DAB because the existing DAB
software thats on my ubuntu box works very poorly with the hw i had
in fact it even has difficulty finding the frequency of the DAB signal
alot of the time. (which is ridiculous)

I have not looked at DVB at all so i cannot comment.
if its a mess, the question is in what way it is a mess.

FFmpeg should have DVB support in some form. whatever external or
internal bits that would use. It should be supported.
GNU radio, a different lib, libavradio, a demuxer, a filter in a future
avfilter API whatever but it should be supported in some form

thx

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

No snowflake in an avalanche ever feels responsible. -- Voltaire

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

Re: [FFmpeg-devel] [RFC] SDR

[Tomas Härdin]

fre 2023-06-23 klockan 23:36 +0200 skrev Michael Niedermayer:
> On Fri, Jun 23, 2023 at 10:19:37PM +0200, Tomas Härdin wrote:
> > fre 2023-06-23 klockan 22:18 +0200 skrev Tomas Härdin:
> > > tor 2023-06-22 klockan 16:57 +0200 skrev Michael Niedermayer:
> > > > If we support just audio and video (de)modulation it fits
> > > > nicely in
> > > > FFmpeg
> > > 
> > > You have no idea what you are getting into. Are we going to
> > > implement
> > > a
> > > DVB-T demuxer in this project? For what purpose? You can just as
> > > well
> > > implement a modem externally that pipes bits into the mpegts
> > > demuxer.
> > 
> > Herp, I obviously mean a DVB-T *modem*
> 
> as said previously i did a AM demodulator, one classical
> implementation
> and one that demodulates it synchronously mapping in phase and
> quadrature
> to mid and side channels or just mono
> The idea of the mid and side channels is that if theres 1 transmitter
> its
> mono, if there are 2 transmitters they will appear to come from
> different
> directions as one listens

There are multiple (quasi-)standards for stereo AM. Then there are
things like DRM.

> 
> And i plan to do FM demodulation.

Drop in a WFM demod box in GNU Radio Companion -> done. Or use fmtools.

> after that i likely have many other non SDR things i want to work on
> and would very much be happy to then find someone else working on
> DAB/DVB
> but if noone does and i find time i might look at DAB because the
> existing DAB
> software thats on my ubuntu box works very poorly with the hw i had
> in fact it even has difficulty finding the frequency of the DAB
> signal
> alot of the time. (which is ridiculous)

There are undoubtedly better DVB implementations around because it is
used in DATV QSOs with the ISS. Indeed this is why you want to have a
separate program just for demodulation so that you get a bitstream that
can then be piped to various other programs. A good DVB demod would
output an MPEG-TS stream that can then be consumed by various programs.

ATV de/mod is another thing that technically could be done in FFmpeg
but shouldn't.

This stuff is also already a part of V4L though I haven't looked into
it particularly deep. Also for comparison, in the FreeDV project we're
looking at writing a TUN/TAP device for packet radio over VHF using
cheap hardware.

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

Re: [FFmpeg-devel] [RFC] SDR

[Michael Niedermayer]

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

On Sat, Jun 24, 2023 at 12:12:50PM +0200, Tomas Härdin wrote:
> fre 2023-06-23 klockan 23:36 +0200 skrev Michael Niedermayer:
> > On Fri, Jun 23, 2023 at 10:19:37PM +0200, Tomas Härdin wrote:
> > > fre 2023-06-23 klockan 22:18 +0200 skrev Tomas Härdin:
> > > > tor 2023-06-22 klockan 16:57 +0200 skrev Michael Niedermayer:
> > > > > If we support just audio and video (de)modulation it fits
> > > > > nicely in
> > > > > FFmpeg
> > > > 
> > > > You have no idea what you are getting into. Are we going to
> > > > implement
> > > > a
> > > > DVB-T demuxer in this project? For what purpose? You can just as
> > > > well
> > > > implement a modem externally that pipes bits into the mpegts
> > > > demuxer.
> > > 
> > > Herp, I obviously mean a DVB-T *modem*
> > 
> > as said previously i did a AM demodulator, one classical
> > implementation
> > and one that demodulates it synchronously mapping in phase and
> > quadrature
> > to mid and side channels or just mono
> > The idea of the mid and side channels is that if theres 1 transmitter
> > its
> > mono, if there are 2 transmitters they will appear to come from
> > different
> > directions as one listens
> 
> There are multiple (quasi-)standards for stereo AM. Then there are
> things like DRM.


> 
> > 
> > And i plan to do FM demodulation.
> 
> Drop in a WFM demod box in GNU Radio Companion -> done.

Goal 1. is support in FFmpeg & FFmpeg based players
Goal 2. is a fun excercise
neither is achieved here
I wonder why you dont see this.

I want to do a fun math excerice, you tell me to use a calculator
I think its quite clear what the difference is, no?
Its not a question IF i will work on this. The question is if i throw
the code away after writing it or if its usefull for someone else.
I think this code is usefull to other FFmpeg users.

> Or use fmtools.

fmscan
fmscan: Unable to open /dev/radio0: No such file or directory

Seems none of the hardware i have supports this

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The smallest minority on earth is the individual. Those who deny 
individual rights cannot claim to be defenders of minorities. - Ayn Rand

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