[FFmpeg-devel] [PATCH] [RFC] Add option for writing detailed filtergraph information to file or stdout

Soft Works softworkz at hotmail.com
Thu Aug 26 12:20:47 EEST 2021



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Thursday, 26 August 2021 11:03
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] [RFC] Add option for writing
> detailed filtergraph information to file or stdout
> 
> Soft Works (12021-08-26):
> > To be clear: I didn't submit this to end up in a LOC count
> discussion.
> 
> Good.
> 
> > My point is that there's much more relevant and important
> information
> > that a filtergraph-information feature should provide than what
> your
> > proposed patch is outputting.
> 
> Which one?

All of what my patch is outputting (and ideally even more).

Please see here for an example:
https://gist.github.com/softworkz/08cd593cebdfb5da3bbe1f6e5683320e

> > comprehensive and provide machine readable output.
> 
> You are wrong on the "machine readable" point, 

No - you are wrong! I do not "want" to print that. I have that in 
place for years and I'm using this information regularly for diagnosing
user issues. 

> more importantly ensuring long-term compatibility. 

When you don't change it, it won't break. As simple as that.

> What you want to print is internal information.

How do you come to that idea? When I specify a filter graph
and perform format conversions, I specify the formats to which 
I want to convert between filters.

And now you want to tell me that the actual formats that have 
been negotiated between filters are "internal"? Like an implementation
detail?
No. Those are not implementation details. I set up a filtergraph
with a specific intention and formats for the individual connections
and that means that knowing about the actually negotiated formats
cannot be considered "internal".

softworkz










> It is useful for debugging and testing purposes but should not be
> accessed by regular tools.









More information about the ffmpeg-devel mailing list