As a frequent FFmpeg user, and an occasional RTL-SDR user, the major tradeoff for me is in the size of FFmpeg binaries vs. features. I agree with Jean-Baptiste that if this were an optional library to be added to the build, then that resolves any issues I might have as a user.
Then I have the choice to opt for the big honkin' beast build that includes all-the-things on my daily dev machine, but can still build targeted builds for deployment to production servers, oddball platforms like WASM, etc. Brad Isbell // AudioPump, Inc. b...@audiopump.co On Wed, Aug 2, 2023 at 7:59 AM Jean-Baptiste Kempf <j...@videolan.org> wrote: > > On Wed, 2 Aug 2023, at 14:55, Michael Niedermayer wrote: > > the code already is in a seperate repository. And is basically isolated > > in a single demuxer and single input device. > > But it's not a library in that repository, like swscale, swresample or > similar libraries. > > If it was, with an API, it would be trivial to add support to this optional > library as an FFmpeg module, and noone who complain. > > jb > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > _______________________________________________ > 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".
