Quoting Andreas Rheinhardt (2021-12-15 13:35:32) > libavcodec currently exports four avpriv symbols that deal with > PixelFormatTags: avpriv_get_raw_pix_fmt_tags, avpriv_find_pix_fmt, > avpriv_pix_fmt_bps_avi and avpriv_pix_fmt_bps_mov. The latter two are > lists of PixelFormatTags, the former returns such a list and the second > searches a list for a pixel format that matches a given fourcc; only > one of the aforementioned three lists is ever searched. > > Yet for avpriv_pix_fmt_bps_avi, avpriv_pix_fmt_bps_mov and > avpriv_find_pix_fmt the overhead of exporting these functions actually > exceeds the size of said objects (at least for ELF; the following numbers > are for x64 Ubuntu 20.10): > The code size of avpriv_find_pix_fmt is small (GCC 10.2 37B, Clang 11 41B), > yet exporting it adds a 20B string for the name alone to the exporting > as well as to each importing library; there is more: Four bytes in the > exporting libraries .gnu.hash; two bytes each for the exporting as well > as each importing libraries .gnu.version; 24B in the exporting as well > as each importing libraries .dynsym; 16B+24B for an entry in .plt as > well as the accompanying relocation entry in .rela.plt for each > importing library. > > The overhead for the lists is similar: The strings are 23B and the > .plt+.rela.plt pair is replaced by 8B+24B for an entry in .got and > a relocation entry in .rela.dyn. These lists have a size of 80 resp. > 72 bytes. > > Yet for ff_raw_pix_fmt_tags, exporting it is advantageous compared to > duplicating it into libavformat and potentially libavdevice. Therefore > this commit replaces all library uses of the four symbols with a single > function that is exported for shared builds. It has an enum parameter > to choose the desired list besides the parameter for the fourcc. New > lists can be supported with new enum values. > > Unfortunately, avpriv_get_raw_pix_fmt_tags could not be removed, as the > fourcc2pixfmt tool uses the table of raw pix fmts. No other user of this > function remains. > > Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com> > --- > 1. It would make sense to deduplicate avpriv_pix_fmt_bps_(mov|avi) > size-wise if it is preferred to keep the lists accessible to users. > 2. One could handle the fourcc2pixfmt case in avpriv_pix_fmt_find(), > too, if one added another parameter (say count). In this case > avpriv_pix_fmt_find() will return the first pixfmt with the desired > fourcc if count is zero, the second one is count is 1 etc. (and > AV_PIX_FMT_NONE in case there is none any more). This would also make > this function more future-proof.
Would it not be simpler to add a second function returning a pointer to the full table? Also, I would prefer making this completely public rather than avpriv. -- 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".
