[FFmpeg-devel] [PATCH 000/279] New channel layout API

[Nicolas George]

James Almer (12021-12-08):
> What is wrong with it? All the functions returning a string in this API use
> the same signature. You pass it a pre-allocated buffer and it's filled with
> the string, truncating it if there's not enough space and letting the user
> know about it.
> I recall you were against dynamic allocation of the string, which the user
> then had to free, so this was the alternative.

There is nothing wrong with it, just as there is nothing wrong with
wearing pelts and a loincloth, but modern clothes are much more
comfortable.

In this case, there is a little usability issue: this description is
almost always very short but can be arbitrarily long, handling that
properly in the caller is very annoying: start with a small buffer on
the stack, try the conversion, if it fails start allocating a bigger
buffer on the heap, etc.

> I could make it use a user provided AVBprint buffer instead of using one
> internally, if you think that's better, but since you planned to replace
> that with AVWriter i figured using AVBprint in the signature would mean an
> eventual deprecation and removal.

We are on the same page on this.

A memory allocation would be a big no here, because it can happen once
every frame. We have implemented pools for frames and buffers, we do
consider once-per-frame to be frequent enough to warrant code to avoid
allocations.

My preferred outcome would be that we apply AVWriter before this series,
and using it here. The idea would be to start using AVWriter everywhere
we return some kind of string: AVWriter in one or two places is crap,
but the more we use it, the more its benefits outweigh the costs.

I will start a new discussion on string API soon, and
since we do not really disagree here but the rest will take
some time, we can continue discussing this later.

Regards,

-- 
  Nicolas George