[FFmpeg-devel] AVWriter API

[Hendrik Leppkes]

On Sun, Jan 12, 2020 at 5:45 PM Josh de Kock <josh at itanimul.li> wrote:
>
>
> Hi,
>
> I have very little time to work on FFmpeg lately but this thread caught
> my interest.
>
> Nicolas George writes:
> > Anton Khirnov (12020-01-07):
> >> And most importantly - strings are simple. Every C programmer (worth the
> >> name) understands strings. But now you'd be forcing every API user to
> >> understand and remember this new API.
> >
> > [...]
> >
> > We will not play the game of reinventing yet another data structure for
> > strings, but let us not play the game of pretending the issue does not
> > exist: it only makes the problem more stinging.
>
> I think this is really important, AVWriter allows the user to make use
> of whichever implementation of strings their application already uses
> and not have to deal with yet-another-string-type.
>

While this argument sounds sensible on the surface, I can't help but
wonder if it really makes sense.
Sure, some returned strings may be able to be wrapped straight into
whatever structure they use. But what about  const char* strings? Will
we need to allocate a buffer and copy those in the future? Considering
I can practically use those inline in logging printfs now, that would
be an extreme increase in complexity.

Also, what happens to strings that are an input to our libraries? Will
those no longer be char pointers, possibly malloc'ed (depending on
where they are used)?

It sounds to me like you won't really be able to get rid of char
pointers, static or malloc'ed, without introducing a lot of pain
points. Sure, typical output functions may give you AVWriter things,
but other things will still  be char*.

Additionally, any widely used custom string class will have a direct
conversion from/to char pointers, so is this really such a huge burden
on application developers? I work on Windows, where everything is
wchar_t, and I never thought this was a problem, since I have to deal
with this for every library. In fact the proposed API won't really
help, since the entire API is still designed around UTF-8, so what I
would do is wrap the dynbuf writter and just convert to wide-char when
the string is complete. In short, I do exactly what I do now, just
more complicated.

Every library outputs strings in a certain manner, its either
char-pointer strings that you get to free, or their own string-type. I
can't help but think that this feels worse and more complicated then
our own string type.

- Hendrik