[FFmpeg-devel] [PATCH 0/4] avdevice/dshow: implement capabilities API

[Anton Khirnov]

Quoting Diederick C. Niehorster (2021-06-09 21:49:28)
> 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?

The problem is that libavdevice is a separate library from libavformat,
but fundamentally depends on accessing libavformat internals.

> 
> > 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)?

Look through the threads
- libavdevice: Add KMS/DRM output device
  started by Nicolas Caramelli on 16 Jan 2021
- avdevice/avdevice: Deprecate AVDevice Capabilities API
  started by Andreas Rheinhardt, on 24 Jan 2021
  a good overview is
  http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2021-January/275158.html

-- 
Anton Khirnov