Quoting Diederick C. Niehorster (2021-06-09 21:49:28) > On Wed, Jun 9, 2021 at 8:18 PM Anton Khirnov <an...@khirnov.net> wrote: > > > > Quoting Diederick C. Niehorster (2021-06-05 16:51:32) > > > On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov <an...@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 _______________________________________________ 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".
