Anton Khirnov (12021-06-09): > > > 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.
Point 3 is just completely unacceptable, as there are applications using libavdevice. Please do not mention it again unless you have new strong arguments about it. As for point 2, I explained at the time (but for some reason you neglected to mention it) that it was a false good idea. Of course, libavdevice is not the same thing as libavformat, and therefore it's obvious they should have different APIs to reflect their specificity. But obvious does not mean true. If we have learned something from object-oriented programming, it's that similar APIs should be merged, not split, so that objects that share common properties can be transparently used with the same code path. If somebody were to make a separate API for libavdevice, the only result would be that all code would ceaselessly go trough compatibility wrappers. A pure waste of time. Here too, if you ever mention it again, please take this argument into consideration. As for point 1, it would be nice to be able to use ff_* functions rather than the avpriv_* hacks. But unless you realize that it should not apply to libavformat/libavdevice but to all the libraries in ffmpeg, let me tell you it is not an efficient use of your time. Still, if you want to use your time inefficiently and turn libavformat+libavdevice into a single linking unit, probably named libavformat, then I have no objection since it is a small step into the right direction. OTOH, please do not touch the directory structure, as it would be annoying and bring no benefit. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
