On Thu, Jun 22, 2023 at 12:10:06PM -0300, James Almer wrote: > On 6/22/2023 12:05 PM, Michael Niedermayer wrote: > > On Thu, Jun 22, 2023 at 10:55:44AM -0300, James Almer wrote: > > > On 6/22/2023 10:43 AM, Michael Niedermayer wrote: > > > > On Mon, Jun 19, 2023 at 12:28:05AM +0200, Michael Niedermayer wrote: > > > > > Signed-off-by: Michael Niedermayer > > > > > --- > > > > > configure | 4 + > > > > > doc/demuxers.texi | 71 ++ > > > > > libavformat/Makefile | 2 + > > > > > libavformat/allformats.c | 2 + > > > > > libavformat/sdrdemux.c | 1739 ++++++++++++++++++++++++++++++++++++++ > > > > > 5 files changed, 1818 insertions(+) > > > > > create mode 100644 libavformat/sdrdemux.c > > > > > > > > Ill post a v3 later today or tomorrow that makes this work with the RTL-SDR Blog V3 > > > > > > Shouldn't the SDR "demuxer" be in libavdevice? Being AVFMT_NOFILE and pretty > > > much a capture device, it seems to me that's the proper place. > > > I guess the problem arises with the sdrfile demuxer, which shares code with > > > the other one. > > > > I have no oppinon on this. I can move it to libavdevice if people prefer. > > do people prefer libavdevice for this ? > > I do. It's a capture device and depends on an external library to interface > with hardware. And like i said, you can keep the file demuxer in lavf, where > it does fit. anyone objects if i move sdrfile then too into libavdevice ? because its the same code basically. Otherwise it would have to be some sort of #include of c file accross libs > > > > > > > personally i think libavdevice should be merged with libavformat. > > It's been suggested plenty of times. Anton attempted to at least kickstart > it once, but his plan was shot down. > No one has tried anything ever since. How was it shut down ? 1. sent patch 2. apply it I think it should be done with the next major ABI bump thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle