Re: [FFmpeg-devel] [RFC] Shaping the AVTextFormat API Surface

[Nicolas George <george@nsup.org>]

Stefano Sabatini (HE12025-05-04):
> I don't understand this claim. There is a root, and each section can
> have several subsections, so it is a tree in my view, although we set
> a maximum depth. Where am I wrong?

Are we looking at the same thing? In ffprobe's output, we have sections
“packets”, “streams”, “format”, etc., and in each section items, but
that does not go deeper.

And in the source code of ffprobe, I see extremely ad-hoc code.

> I agree with softworkz on this. The AVTextFormat functionality is not
> about a specific format, it's supposed to be a generic way to
> represent a data tree using different formats. Being able to provide
> this generic representation is crucial, since we want a single entry
> point to represent data in a way which can be parsed in various ways,
> given a data schema.

Is this API meant to be a generic API for writing structured data, or is
it meant to be totally specific to ffprobe and usable by one other use
case that was designed to behave exactly like ffprobe.

An API that is not generic should not go into libavutil.

An API that cannot serve all, or at least most of, our currently
existing use cases cannot be called generic.

> If we want to add support for a specific format encoder (e.g. XML,
> JSON), it might be *used* by the AVTextFormat API, not be
> *implemented* by the AVTextFormat.

Which is exactly what I told softworkz should start with.

Making this API generic is not an easy task, but it is doable. We should
not settle for an inferior API just because the person who proposed it
wrote the code before designing it properly and now is in a hurry to get
it applied.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".