On Thu, Dec 31, 2020 at 2:35 PM <Nicolas George> wrote: > > This mail is about a project I have to make FFmpeg's API and > infrastructure more convenient. For a common introduction, see this > thread: > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html > > For each simple type, including enumerations like AVColorRange and flat > structures like AVReplayGain, have a set of standardized functions for > common operations, including probably: > > - printing; > - serializing to string; > - parsing from string; > - serializing to/from compact binary form; > - freeing; > - referencing or cloning. > > These functions will have a standardized name and prototype. They will be > grouped in structures that describe a type entirely.
Strong +1. Such code is spread all over the code base, and sometimes hard to discover due to variety in naming and location (as an API user, I often end up grepping ffmpeg source for a to_string or from_string function until i find one, and then grep again for example use). Consistency like the proposed struct of functions would be great! How to get the relevant info for a given type? Some type of type registry? This relates importantly to options and how to parse/print those. There is a limited set of option types (e.g. there is AV_OPT_TYPE_PIXEL_FMT but not AV_OPT_TYPE_CODEC_ID), none of which should be needed by simply linking each option to the right type description struct. Would save me half a headache when using the device capabilities API (see https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281379.html for at least two non-ideal solutions to formatting some of the information it returns--we shouldn't need any new API for this at all). Cheers, Dee _______________________________________________ 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".
