On 25/01/2021 17:11, James Almer wrote:
Mark then suggested to directly replace/extend the API with one that's more useful in the long run, instead of removing them as Anton suggested since you and some other devs stated they in fact do have users, and you agreed to that. So how about we try to move in that direction?
Yes.
The first step is merging the libraries, ...
? I don't see how this follows at all. Merging the libraries (in source form, orthogonal to merging the binaries) only makes sense if we are going to continue using the libavformat internals, and that is exactly the thing we are trying to get rid of. If we replace the libavdevice API with a proper one oriented towards devices rather than being hacked on to the libavformat API then we actively don't want that merger. So, what do people actually want here? The situation as I see it is (please correct me on anything you feel is in error here): * The features which libavdevice offers are useful to a lot of people. * Many of those are using it via the ffmpeg utility, but not all. * The libavdevice API is the libavformat API because it was originally split out from libavformat, and it has the nice property that devices and files end up being interchangable in some contexts. * The libavdevice API, being the libavformat API for files, is not particularly well-suited in other contexts, because devices may not have the same properties as files. * Some odd things like the completely-unused capabilities API and the almost-never-used message API are hacked on top of that to try to avoid some libavformat issues, but are not actually useful to anyone (hence the lack of use). * To implement devices as AVInputFormat/AVOutputFormat instances, libavdevice currently needs access to the internals of libavformat. * Many developers want to get rid of that dependency on libavformat internals, because it creates a corresponding ugliness on the libavformat side which has to leave those parts exposed in an ABI-constrained way. What might we do about this: * Delete libavdevice, with a statement that its capabilities are outside the scope of ffmpeg. Obviously this isn't sensible, the ffmpeg utility would then need to depend on some external library to offer the same features it does now. * Merge libavdevice into the ffmpeg utility. Since it is the primary user this would neatly sidestep the previous objection, but now external users are in the same boat so again unacceptable. * Merge libavdevice into libavformat. This works to eliminate the dependency problem, but it only really makes sense if we accept that libavdevice is finished and will never want new API which isn't repurposed libavformat. * Make a new libavdevice-specific API and switch to that. The eliminates the dependency problem, but there is a nasty transition period and it would break the interchangability of the two libraries. It also would be the most work, but leave libavdevice in the best state for doing more things with in future. * Nothing. People will continue to be annoyed about the problems above. Opinions? Personally, I think the right option here is to make a new libavdevice-specific API and cut the connection to libavformat entirely, and I would be prepared to do some work towards that goal. Exactly what form it would take is unclear, but I would be happy to talk about that further if people agree that it is the right approach. Thanks, - Mark _______________________________________________ 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".
