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. > 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. 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".
