[FFmpeg-devel] AVWriter API

[Josh de Kock]

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.

> Who wants a mallocated char pointer, really? Who things it is a good
> idea for a string?
>
> Not applications that use another allocator than malloc(), obviously.

Not relevant to this thread but: How would an application not using the
traditional malloc() allocator work use FFmpeg at all if it didn't 'just
work' by setting MALLOC_PREFIX?

> [...]
>
> Etc. I hope you see my point and I do not need to add Java and PHP to
> these examples.

It's an issue that everyone is making their own string type, we do
definitely not want to do this (one of the reasons I think this API is
in the right direction).

> By returning a mallocated char *, you are saying to the authors of these
> applications "screw you, I don't care about your use case". If you don't
> care about most applications' use cases, don't design public APIs.

I guess the argument against this would be 'well, you can just copy it
to whichever string implementation you need', which maybe isn't ideal
but it 'works' currently.

> This AVWriter API addresses all that. If the caller wants a mallocated
> char *, they can get it, with almost no extra code. But if they want
> something else, they can get it.

Important that we won't lose any functionality with this new API.

> And even if it is used only for a mallocated char *, this code still
> brings the benefit of factoring error checks. Error checks are "not to
> be avoided", but they are not to be littered all over the code either:
> they are often tricky, with the risk of leaks or double frees, and they
> are almost never tested. Any change that centralizes them is good to
> take, and this one of the things AVWriter does, centralize error checks.

Deferring error checks properly and centralising them means they can be
better handled by a user. This is a good approach.

> As for the extra complexity. Yes, there is some. There is some
> significant complexity in the implementation, of course. If it is
> anybody's problem, it's mine.
>
> There is a little complexity for the caller. Look at the code: very very
> little complexity. Much less than what is required learning to use any
> FFmpeg API anyway.
>
> There is no complexity for the callee. If anything, using AVWriter makes
> the callee code simpler.

I don't think the complexity is a big issue here.

> I understand that you may be reluctant to embrace creative APIs, but
> please try to go beyond that reluctance to see the actual benefits and
> costs.

For the most part I think the concept is good, and it definitely solves
a problem which exists but the million dollar question is:

Are strings a big enough issue at the moment that we should introduce a
new API to fix them?

Though I guess if someone is willing to implement a fix, then the answer
to this doesn't even matter at all, and should always be 'yes'--you have
my support for this set, at least.

--
Josh