Anton Khirnov (12023-04-29): > As far as I can see, there are exactly two places in the codebase that > produce JSON: af_loudnorm and ffprobe.
I think I remember finding a few other places, but it does not matter much. Users have been asking¹ for parse-friendly output from filters for years, and JSON is often the format they prefer. Therefore, all the filters that log useful information are candidates where a JSON writing API is useful. (See my answer to James for why “put it in frame metadata” is not a real solution.) > * IMO the filter should not be doing this at all and instead produce some > sort of a struct and let the users process it as they wish And to let users process it as they wish, it needs to be formatted into a parse-friendly syntax like JSON. > ffprobe: > * is not one of the libraries, but rather their caller > * we are not in business of providing random non-multimedia-related > services to callers, unless they are useful in our libraries; > if this code is only useful in ffprobe then it should live in fftools/ This is your opinion, not the project policy. My opinion is that anything that is useful for fftools and can be made to have a properly-defined API has its place in libavutil. Let us see which opinion has more support. > * it is not at all obvious that switching ffprobe to this code would > be an improvement; a patch actually demonstrating this would be most > useful I distinctly remember writing the changes to ffprobe and getting the same output except for the indentation level, but I do not find the code. 1: To be aware what would be useful to the project, reading the users mailing-lists helps. -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
