[FFmpeg-devel] [RFC] Moving ffprobe's writers to lavu

[Jan Ekström]

Hi,

On Fri, Apr 10, 2020 at 5:27 PM Nicolas George <george at nsup.org> wrote:
>
> Hi.
>
> In the comments on a recent patch to implement statistics outputs for a
> specific filter, I noted that this is something that many filters need
> to do, and therefore in need of unification. I also observed some JSON
> code in a filter, which does not belong there.
>
> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/260178.html
>
> It reminded me of a project I have had for some time: moving the writers
> written for ffprobe (XML, JSON, INI, etc.) into libavutil.
>

I think this all depends on how much of a use there is for this sort of thing.

Just looking at the case of wanting to output data from a filter, I
would default to the opinion that it would make sense to have these
writers (or at least some of them) common to the fftools tooling. Then
common code in the API clients could be written that would utilize the
metadata or side data that these filters generate.

Of course, (unfortunately and without actually looking) I would bet
right now there would be not so much normalization with these filters'
output, but it would make much more sense to have a common way of
pushing data out with the frames (be it side data or metadata), which
then could be pushed out in a required format by the API client. And
then an example could be added under doc/examples to show API users
how to output data produced by filters.

If you have a feeling there's a specific need for this to be available
through the library to all components, I would like to hear the
reasoning. My default would be that the API client should handle
dumping the data exported by filters into wherever the API client
requires (memory, file, JSON, XML).

> I am pretty sure it is doable, but I am also sure there will be
> pitfalls, cases where the writer are very specific to ffprobe's need and
> some careful design is needed to make them generic while keeping
> compatibility.
>
> And in any case, it will be quite some work, I do not want to do it if
> it will be bikeshedded to death, so I first put the principle on
> discussion here.
>
> Do you think it is a good idea to add functions to produce formatted
> output for structured data in libavutil?
>
>
> There is another, smaller pitfall: where do these functions output to?
> ffprobe outputs to stdout; the patch quoted above outputs through AVIO
> to any supported format; some filters put data as string metadata. The
> obvious answer to that is to "write" to a callback, and have the
> callback decide to write the data to stdout, AVIO or a memory buffer.
>
> A few months ago, I proposed the draft of an elegant (IMNSHO) API for
> "write to a callback", but it immediately gave signs to be bikeshedded
> to death. If I start working on this project, I intend to finish and use
> it, because it's exactly the kind of use I had in mind for it.
>
> https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/254042.html
>
> Please share your thoughts, including if only to say you think it is a
> good idea.
>
> Regards,
>
> --
>   Nicolas George
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".