On date Tuesday 2025-04-29 10:30:55 +0200, Nicolas George wrote: > Stefano Sabatini (HE12025-04-27): > > Elaborating on this. ffprobe/textformat is based on a notion of > > hierarchical tree-like data >
> No, this is not true. FFprobe and all its supporting code is based on > one level of hierarchy. Just one level, not a real hierarchical > structure. 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? > > Considering this, there is probably no need to extend the API to cover > > each possible format full semantics - this at least it is my view. > > If we add XML-writing code in libavutil, it must be usable for all the > places we are already producing XML. Otherwise it does not make sense. > > > As I wrote, this was not the purpose of the ffprobe formats in the > > first place. MOV/DASH requires a specific use of an XML encoder. In > > theory it might be done using the textformat API in the current form, > > but it would be probably pretty awkward. We might want to factorize a > > few generic utilities (e.g. escaping) to avoid code duplication > > though. > > You are going at it backwards. > > The goal is not to cram this text writers API forcefully into libavutil > and then see if it might serve other purposes, which is what softworkz > is doing. > > The API must be able to handle all our use cases from the start. Until > then, it goes back to the design board. > > > It might be if we want to make this a generic tool for library users, > > and for purposes outside of the scope for which it was designed. But I > > don't think this should be a real blocker - and we might even keep the > > API private to enable libav* cross-librariers but not > > external-libraries usage. > > I can concede making a generic API for external users is not blocking. > Reluctantly. > > But I will not budge on internal uses: this API must serve all our > current use cases or it stay outside the libraries. 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. 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. _______________________________________________ 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".
