[FFmpeg-devel] [RFC] SDR Vote

[Michael Niedermayer <michael@niedermayer.cc>]

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

Hi all

On VDD I was asked about (not) listing a release with SDR on the download page
and IIRC the consensus was to do a vote on it.
As you notice i am a bit hesitant to start a vote because its always better
to find solutions evereyone is happy with and not just a majority.

I also would prefer this vote to be done by someone neutral and not me
but i failed to find a volunteer for that (and i tried).

So if i have to make this vote, the plan would be to take the GA
list of people posted in the last VDD mail. And use vote.ffmpeg.org
(maybe make a test vote first, iam not sure)

and then vote about the 2 main Questions, both independantly, they seem
simple yes/no votes.

The first Vote is, SDR in git master yes/no.
(a no implies that i will maintain a seperate fork of FFmpeg with SDR)

We could also make these 2 options more elaborate:
* Two FFmpegs, one official FFmpeg without SDR. And one inofficial maintained by Michael with all
  features including the self contained SDR avdevice/demuxer.
OR
* One FFmpeg, including the self contained SDR avdevice/demuxer.

(self contained SDR avdevice/demuxer.) is the code as it is in the libavradio repository
that is currently:
https://git.ffmpeg.org/gitweb/libavradio.git/commitdiff/886e4ed6521e288a5723a9896dc1cf96af127630?hp=a47afb80840e5ecd5eaf2d583e9a042805ad204a
All suggested cleanup and fixes people might find, will of course be done before applying


The 2nd question is
*. Our download page shall only list the official FFmpeg release / repositories
OR
*. FFmpeg developers can list their maintained FFmpeg forks on the download page
   These shall be listed with some description and the name or alias of the maintainer(s).


What about the external library?
* No volunteer to design or even talk about the API,
  no volunteer to maintain seperate build system and testing infra.
* Inconvenient at this stage for developing the code, API/ABI gets too entangled into design decissions, so
  internal design has to settle down first IMO. OR API has to be very high level but then its a clone of
  avdevice API and some people opposed that too.
so its git master or fork or sdr code dies really
and i dont want the code to die
and so we end with this RFC, and if noone comes up with a practical/realistic
alternative then a vote.

A problem is that there is a divide between the developers making decissions
about the SDR code (for example asking for an external library) and
the developers working on the SDR code. This is a difficult setup. Normally
we have people maintaining / working on / being affected by / being the authors of
some code making decissions about 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".