[FFmpeg-devel] [RFC] Type descriptors

Diederick C. Niehorster dcnieho at gmail.com
Sat Jun 12 22:14:12 EEST 2021


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


More information about the ffmpeg-devel mailing list