On 6/22/2023 1:26 PM, Michael Niedermayer wrote:
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 <mich...@niedermayer.cc>
---
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
It does not belong in lavd. The doxy in avdevice.h states "the
(de)muxers in libavdevice are of the AVFMT_NOFILE type". And you can
make the common code avpriv_ since both libraries are basically version
locked. There's no need to duplicate it, but if you prefer that, you can
indeed do an #include c file using the SHLIBOBJS list in Makefile which
will trigger on shared builds.
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
[...]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
