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-requ...@ffmpeg.org with subject "unsubscribe".
