On Tue, 25 Feb 2014, Vittorio Giovara wrote:
--- This was identified as one of the last remaining functions that interweaved lavc and lavf badly, so at our fosdem meeting it was suggested to move the common parts into lavu.
I'm not sure if I didn't listen carefully, somebody misunderstood something or this was something that was discussed after I left for the airport, but...
What concrete problem does this solve? lavf and lavc have got some tight dependencies but I don't see this solving or changing any of them in any significant way.
I'm not against it as a concept, but the exact reasonings need to be explained in the patch, not just briefly summarized, because the reasons behind the patch (and the issues you are trying to solve) are way more important than the patch itself.
Additionally a few concrete issues with this patch: mathops.h refers to ff_sqrt_tab, which is declared within libavcodec. Having such a function defined in libavutil only makes the mess worse. Right now with your patch it just works by magic coincidence - the declaration is in libavutil, but the table is in libavcodec, which just happens to work as nobody outside of libavcodec uses it.
(Reminder; using static data tables across shared libraries in MSVC land is an additional mess we've chosen not to do at all, so moving the table to libavutil and using it from libavcodec is something that we would not like to unless we really have to.)
Also, why move mathops.h at all? To me it seems to be a libavcodec internal header, mostly. The only other user outside of libavcodec is libavformat/mpegts.c, which doesn't use the static data tables and all that. Instead if you really want to "fix" that, which isn't an issue in itself, you would split the macros that are used from libavformat into a separate header (which can be moved to libavutil if you want to).
// Martin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
