[FFmpeg-devel] [PATCH 0/4] avdevice/dshow: implement capabilities API
Diederick C. Niehorster
dcnieho at gmail.com
Wed Jun 9 22:49:28 EEST 2021
On Wed, Jun 9, 2021 at 8:18 PM Anton Khirnov <anton at khirnov.net> wrote:
>
> Quoting Diederick C. Niehorster (2021-06-05 16:51:32)
> > On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov <anton at khirnov.net> wrote:
> > > Sorry to rain on your parade, but I don't think we should go ahead with
> > > this before deciding what is to be done with libavdevice. The last
> > > discussion about it died without being resolved, but the issues are
> > > still present.
> >
> > I understand. I realize I'm new here: Is there a timeline for such a
> > discussion and could the discussion benefit from a real usage example
> > such as this patch series? I guess a big change in libavdevice should
> > at least offer the functionality the current implementation offers (or
> > theoretically offers :p). I really like the current design where an
> > avdevice can just be used through the avformat interface. Add
> > avdevice_register_all(); and Bob's your uncle!
>
> There is no timeline, it depends on someone sitting down and doing the
> work. The options proposed so far were
> 1) merging libavdevice into libavformat
> 2) making libavdevice into an independent library with an independent
> API
> 3) moving libavdevice functionality into ffmpeg.c
Thanks for providing the explored options. What problem is there in
the way things currently are that these would be solving?
> I volunteered to do 1), but was stopped by some issues and Mark
> volunteering to do 2). But Mark did not progress far on that apparently,
> so now we are stuck. Maybe we should do a technical committee vote on
> it.
While not being familiar with the alternative, as said, from my
perspective whats great about the current setup is that avdevices act
just like formats, making them easy to integrate. And for devices that
actually implement functions like get_device_list, control_message and
create_device_capabilities, they are also directly explorable and
controllable like an independent API would presumably allow. Best of
both worlds in my book.
Could you point me to previous discussions regarding options 1 and 2,
if they are available somewhere to read, so i can have a more informed
opinion (in case that would carry any weight)?
Thanks and all the best,
Dee
More information about the ffmpeg-devel
mailing list