[FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization

[FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization

[Soft Works]

Hello everybody,


working on the subject of writing out filtergraph information obviously implies the goal of being able to visualize that data in some way. While I do have something for long, it's tailored for specific workflows and is hardly useful for most.
Anyway, it shouldn't be required to use once another software for visualize the output. This decimates the usability for any such feature by far.
Few days ago, I was thinking about ways for making this feature really useful for everybody without needing to jump through any extra hoops. We have that range of writers (now "text formatters"), and so I wondered whether there isn't some text format that is meant to directly represent a graph for visualization, which finally reminded me about


MERMAID

Had used it just twice or thrice on GitHub for simple things, and as I found out later, it's by far less capable than I would have expected (more than a decade of age, current version 11.x) --- but: it has a number of unique selling points:

- The format is simple and transparent
- It's hand-editable and easily readable
- There's quite an ecosystem around it with many integrations and tools available
  The #1 for me though is:
- It goes hand-in-hand with Markdown
  => almost everywhere Markdown is supported, Mermaid diagrams are supported as well

Practically, this means that you can paste a Mermaid diagram into any message field on GitHub (for example; forgejo supports it as well as many others) - and the diagram is rendered automatically with a kind of interactive viewer.
Enough reason to give it a try and I also had some quick success. Writing that format fits rather well into the logic of the existing text formatters without major changes.
That way I ended up with a new 


avtextformatter_mermaid ("mermaidwriter" in old terminology)

Most of the mentioned deficiencies could be remedied by CSS styling (even though it's been really tedious). 
Now well - when viewing filtergraphs, you often want to know details about the input and output streams. For that other tool I was parsing out this information from the ffmpeg log lines describing the streams on startup. But this work is happening right at the source of information, so I added input/output files and streams to the filtergraph printing as well (just as much detail as needed for graphing).
The unthankful effect: by that, it became apparent that something else is missing: encoders and decoders - added those as well and eventually got reasonable results.
Remained one last part:


Usability

Of course, it's still not a great experience when you need to copy/paste the generated diagram code in some web portal. To solve that, I've created once another textformatter(writer): mermaidhtml.
It's just an extension to the Mermaid formatter which wraps the diagram as an html file for local viewing (yet not fully offline).
The final idea would be to simplify usage as much as possible, so that all you need to do is adding a small option to the Ffmpeg command line, like -sg ('show graph') which would cause Ffmpeg to create such mermaid html file on exit and automatically launches the browser (if any) to view that file. 
While working or trying a range of commands, after another, this will also create a browser tab for each run, allowing for easy comparison between recent commands.


Examples

I've created a Gist with some examples of the output here:

https://gist.github.com/softworkz/a196b2d0e9e2df49f766abd92f508551

(also includes a zip with html file examples)



Questions

I'm curious what you think about it!

- What's good, what's bad, what should be changed/improved?

- What about the displayed information, should something be added?

- I'm folding out the buffer source/sink filters to simplify the view, is that ok?
  Should the TRIM filters be excluded as well?

- Since it's no longer just about filter graphs - what do you think about the term
  "Ffmpeg Execution Graph"?
  (other ideas welcome)

- Does anybody have some complex command lines for me to test?
  (no need to include media files, I can try to replicate 
  something similar)


Thanks,
sw







_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization

[Diederick C. Niehorster]

On Tue, Mar 18, 2025 at 3:32 AM Soft Works
<softworkz-at-hotmail.com@ffmpeg.org> wrote:
>
> Examples
>
> I've created a Gist with some examples of the output here:
>
> https://gist.github.com/softworkz/a196b2d0e9e2df49f766abd92f508551
>
> (also includes a zip with html file examples)

Just speaking as a would be user of this feature: awesome!!
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization

[Stefano Sabatini]

On date Tuesday 2025-03-18 02:32:13 +0000, Soft Works wrote:
> Hello everybody,
>  
> working on the subject of writing out filtergraph information
> obviously implies the goal of being able to visualize that data in
> some way. While I do have something for long, it's tailored for
> specific workflows and is hardly useful for most.
>
> Anyway, it shouldn't be required to use once another software for
> visualize the output. This decimates the usability for any such
> feature by far.  Few days ago, I was thinking about ways for making
> this feature really useful for everybody without needing to jump
> through any extra hoops. We have that range of writers (now "text
> formatters"), and so I wondered whether there isn't some text format
> that is meant to directly represent a graph for visualization
[...]
> Examples
> 
> I've created a Gist with some examples of the output here:
> 
> https://gist.github.com/softworkz/a196b2d0e9e2df49f766abd92f508551
> 
> (also includes a zip with html file examples) 
> Questions
> 
> I'm curious what you think about it!
> 
> - What's good, what's bad, what should be changed/improved?
> 
> - What about the displayed information, should something be added?
> 
> - I'm folding out the buffer source/sink filters to simplify the view, is that ok?
>   Should the TRIM filters be excluded as well?
> 
> - Since it's no longer just about filter graphs - what do you think about the term
>   "Ffmpeg Execution Graph"?
>   (other ideas welcome)
> 
> - Does anybody have some complex command lines for me to test?
>   (no need to include media files, I can try to replicate 
>   something similar)
> 

Thanks for working on this, from the examples it looks pretty amazing.

What it's not clear to me is how this builds up on top of text
formatters, since they are meant to render a tree structure in a
generic way. From this you can have a description of a graph, but then
you need specialized ad-hoc logic to convert it to a graph format.

What am I missing?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Stefano Sabatini
> Sent: Freitag, 21. März 2025 19:27
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization
> 
> On date Tuesday 2025-03-18 02:32:13 +0000, Soft Works wrote:
> > Hello everybody,
> >
> > working on the subject of writing out filtergraph information
> > obviously implies the goal of being able to visualize that data in
> > some way. While I do have something for long, it's tailored for
> > specific workflows and is hardly useful for most.
> >
> > Anyway, it shouldn't be required to use once another software for
> > visualize the output. This decimates the usability for any such
> > feature by far.  Few days ago, I was thinking about ways for making
> > this feature really useful for everybody without needing to jump
> > through any extra hoops. We have that range of writers (now "text
> > formatters"), and so I wondered whether there isn't some text format
> > that is meant to directly represent a graph for visualization
> [...]
> > Examples
> >
> > I've created a Gist with some examples of the output here:
> >
> > https://gist.github.com/softworkz/a196b2d0e9e2df49f766abd92f508551
> >
> > (also includes a zip with html file examples)
> > Questions
> >
> > I'm curious what you think about it!
> >
> > - What's good, what's bad, what should be changed/improved?
> >
> > - What about the displayed information, should something be added?
> >
> > - I'm folding out the buffer source/sink filters to simplify the view,
> is that ok?
> >   Should the TRIM filters be excluded as well?
> >
> > - Since it's no longer just about filter graphs - what do you think
> about the term
> >   "Ffmpeg Execution Graph"?
> >   (other ideas welcome)
> >
> > - Does anybody have some complex command lines for me to test?
> >   (no need to include media files, I can try to replicate
> >   something similar)
> >
> 
> Thanks for working on this, from the examples it looks pretty amazing.
> 
> What it's not clear to me is how this builds up on top of text
> formatters, since they are meant to render a tree structure in a
> generic way. From this you can have a description of a graph, but then
> you need specialized ad-hoc logic to convert it to a graph format.
> 
> What am I missing?


Hehe, that's been a bit tricky indeed, but more in terms of figuring out that (and how) it can fit into the writer/textformatter patterns, the result is rather simple and it requires only some moderate extensions to the writer/formatter APIs:


It is using a Mermaid Flowchart graph with only 3 kinds of elements:

- Shapes
  i.e. "boxes", can't be nested
- Subgraphs
  Container for shapes, can be nested
- Links
  connection from one shape to another


A simple graph with 2 shapes in a subgraph looks like this:

...
flowchart TD
 subgraph s1["Subgraph 1"]
        A("Shape A") --> B("Shape B")
  end
...

There's a link from A to B - but: it can also be written in a different way:

...
flowchart TD
 subgraph s1["Subgraph 1"]
        A("Shape A")
        B("Shape B")
  end

  A --> B
...

This does the same thing. The link definitions can be at a different place in the document - which is one of the key points to make it work.

Then there are three new section flags to denote subgraph, shapes and links and two fields in the section struct (source_id_key, dest_id_key). For link-producing sections they indicate the names of the keys to use for building a link. A section can also produce both - shapes and links when the flags are set accordingly.
I also use another (existing) mechanism, which is the data object that can be provided on section start, only that it's a (publicly) defined "SectionContext" struct, which is a somewhat alternative direction. I kept it for the moment as suggestion because I didn't know which ideas you have for the API to evolve, so that's just something for discussion.

Best,
sw

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization

[Stefano Sabatini]

On date Friday 2025-03-21 20:11:29 +0000, Soft Works wrote:
[...]
> > What it's not clear to me is how this builds up on top of text
> > formatters, since they are meant to render a tree structure in a
> > generic way. From this you can have a description of a graph, but then
> > you need specialized ad-hoc logic to convert it to a graph format.
> > 
> > What am I missing?
> 
> 
> Hehe, that's been a bit tricky indeed, but more in terms of figuring
> out that (and how) it can fit into the writer/textformatter
> patterns, the result is rather simple and it requires only some
> moderate extensions to the writer/formatter APIs:
> 
> 
> It is using a Mermaid Flowchart graph with only 3 kinds of elements:
> 
> - Shapes
>   i.e. "boxes", can't be nested
> - Subgraphs
>   Container for shapes, can be nested
> - Links
>   connection from one shape to another
> 
> 
> A simple graph with 2 shapes in a subgraph looks like this:
> 
> ...
> flowchart TD
>  subgraph s1["Subgraph 1"]
>         A("Shape A") --> B("Shape B")
>   end
> ...
> 
> There's a link from A to B - but: it can also be written in a different way:
> 
> ...
> flowchart TD
>  subgraph s1["Subgraph 1"]
>         A("Shape A")
>         B("Shape B")
>   end
> 
>   A --> B
> ...
> 
> This does the same thing. The link definitions can be at a different
> place in the document - which is one of the key points to make it
> work.
> 
> Then there are three new section flags to denote subgraph, shapes
> and links and two fields in the section struct (source_id_key,
> dest_id_key). For link-producing sections they indicate the names of
> the keys to use for building a link. A section can also produce both
> - shapes and links when the flags are set accordingly.  I also use
> another (existing) mechanism, which is the data object that can be
> provided on section start, only that it's a (publicly) defined
> "SectionContext" struct, which is a somewhat alternative
> direction.

So basically a graph can be represented as a collection of subraphs,
each subgraphs containing shapes, and links.

> I kept it for the moment as suggestion because I didn't
> know which ideas you have for the API to evolve, so that's just
> something for discussion.

One of the possible uses is to expose the data printed by
filters. E.g. detection filters are printing the information either in
the stderr using custom formats, this should really be converted to
something easier to consume (whatever formats for which you don't
need a custom parser).

The metadata muxer also might benefit from using a text writer, to
avoid again the need for a custom parser, and probably there are more
use cases easy to spot.

So at some point we want to make this API accessbile from the
libraries, that is to move them into libavutil. Again, it's fine to
expose this at the tools level first so we can experiment and refine
the interface before moving to a stable one.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Stefano Sabatini
> Sent: Mittwoch, 26. März 2025 23:53
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization
> 
> On date Friday 2025-03-21 20:11:29 +0000, Soft Works wrote:
> [...]
> > > What it's not clear to me is how this builds up on top of text
> > > formatters, since they are meant to render a tree structure in a
> > > generic way. From this you can have a description of a graph, but
> then
> > > you need specialized ad-hoc logic to convert it to a graph format.
> > >
> > > What am I missing?
> >
> >
> > Hehe, that's been a bit tricky indeed, but more in terms of figuring
> > out that (and how) it can fit into the writer/textformatter
> > patterns, the result is rather simple and it requires only some
> > moderate extensions to the writer/formatter APIs:
> >
> >
> > It is using a Mermaid Flowchart graph with only 3 kinds of elements:
> >
> > - Shapes
> >   i.e. "boxes", can't be nested
> > - Subgraphs
> >   Container for shapes, can be nested
> > - Links
> >   connection from one shape to another
> >
> >
> > A simple graph with 2 shapes in a subgraph looks like this:
> >
> > ...
> > flowchart TD
> >  subgraph s1["Subgraph 1"]
> >         A("Shape A") --> B("Shape B")
> >   end
> > ...
> >
> > There's a link from A to B - but: it can also be written in a
> different way:
> >
> > ...
> > flowchart TD
> >  subgraph s1["Subgraph 1"]
> >         A("Shape A")
> >         B("Shape B")
> >   end
> >
> >   A --> B
> > ...
> >
> > This does the same thing. The link definitions can be at a different
> > place in the document - which is one of the key points to make it
> > work.
> >
> > Then there are three new section flags to denote subgraph, shapes
> > and links and two fields in the section struct (source_id_key,
> > dest_id_key). For link-producing sections they indicate the names of
> > the keys to use for building a link. A section can also produce both
> > - shapes and links when the flags are set accordingly.  I also use
> > another (existing) mechanism, which is the data object that can be
> > provided on section start, only that it's a (publicly) defined
> > "SectionContext" struct, which is a somewhat alternative
> > direction.
> 
> So basically a graph can be represented as a collection of subraphs,
> each subgraphs containing shapes, and links.

Yes, and link can exist at the top level (of nesting) and otherwise at any position in the document.


> > I kept it for the moment as suggestion because I didn't
> > know which ideas you have for the API to evolve, so that's just
> > something for discussion.
> 
> One of the possible uses is to expose the data printed by
> filters. E.g. detection filters are printing the information either in
> the stderr using custom formats, this should really be converted to
> something easier to consume (whatever formats for which you don't
> need a custom parser).
> 
> The metadata muxer also might benefit from using a text writer, to
> avoid again the need for a custom parser, and probably there are more
> use cases easy to spot.
> 
> So at some point we want to make this API accessbile from the
> libraries, that is to move them into libavutil. Again, it's fine to
> expose this at the tools level first so we can experiment and refine
> the interface before moving to a stable one.
> _______________________________________________

Yes, I see quite a number use cases as well.
It's still a work in progress, but I've set up a GitHub repo for documentation and as a place of interaction. It's not for ffmpeg code, but there are tests, examples and a documentation Wiki:

https://github.com/softworkz/ffmpeg_output_apis/wiki

(a number of things are still incomplete)


I'm also exploring a way for self-printing the data schema for each use case. On the repo Wiki there are Entity-Relationship diagrams for the FFprobe and the Graphs schema. I'll follow up with more details..

sw






_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization

[Nicolas George]

Stefano Sabatini (HE12025-03-26):
> One of the possible uses is to expose the data printed by
> filters. E.g. detection filters are printing the information either in
> the stderr using custom formats, this should really be converted to
> something easier to consume (whatever formats for which you don't
> need a custom parser).
> 
> The metadata muxer also might benefit from using a text writer, to
> avoid again the need for a custom parser, and probably there are more
> use cases easy to spot.

For the record, I have had detailed plans for all this for years. But
since it is very related to strings, it requires AVWriter, and it
requires the abstraction and type description layer that I want to
introduce that starts with AVWriter. Therefore, it cannot go forward
unless FFmpeg has once more proper leadership able to greenlight it.

> So at some point we want to make this API accessbile from the
> libraries, that is to move them into libavutil. Again, it's fine to
> expose this at the tools level first so we can experiment and refine
> the interface before moving to a stable one.

I wild recommend using the fftools as a staging area.

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Donnerstag, 27. März 2025 20:28
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization
> 
> Stefano Sabatini (HE12025-03-26):
> > One of the possible uses is to expose the data printed by
> > filters. E.g. detection filters are printing the information either in
> > the stderr using custom formats, this should really be converted to
> > something easier to consume (whatever formats for which you don't
> > need a custom parser).
> >
> > The metadata muxer also might benefit from using a text writer, to
> > avoid again the need for a custom parser, and probably there are more
> > use cases easy to spot.
> 
> For the record, I have had detailed plans for all this for years. But
> since it is very related to strings, it requires AVWriter, and it
> requires the abstraction and type description layer that I want to
> introduce that starts with AVWriter. 

Hi Nicolas,

after doing all this, I came to the conclusion that a better string API would really be useful for these kinds of things (albeit not a necessity).

I thought I might take another look, could you point me at the latest version of your work in this regard?

> > So at some point we want to make this API accessbile from the
> > libraries, that is to move them into libavutil. Again, it's fine to
> > expose this at the tools level first so we can experiment and refine
> > the interface before moving to a stable one.
> 
> I wild recommend using the fftools as a staging area.

Yup, that's what we're doing. There's quite a range of improvements I'm seeing which should be done before making anything public.

sw



_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1140 bytes --]

Hi

On Thu, Mar 27, 2025 at 08:27:45PM +0100, Nicolas George wrote:
> Stefano Sabatini (HE12025-03-26):
> > One of the possible uses is to expose the data printed by
> > filters. E.g. detection filters are printing the information either in
> > the stderr using custom formats, this should really be converted to
> > something easier to consume (whatever formats for which you don't
> > need a custom parser).
> > 
> > The metadata muxer also might benefit from using a text writer, to
> > avoid again the need for a custom parser, and probably there are more
> > use cases easy to spot.
> 
> For the record, I have had detailed plans for all this for years. But
> since it is very related to strings, it requires AVWriter, and it
> requires the abstraction and type description layer that I want to
> introduce that starts with AVWriter. Therefore, it cannot go forward

can you repost the AVWriter patches ?

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> softworkz .
> Sent: Donnerstag, 27. März 2025 00:26
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Stefano Sabatini
> > Sent: Mittwoch, 26. März 2025 23:53
> > To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [RFC] FFmpeg Execution Graph Visualization
> >

[..]

> > One of the possible uses is to expose the data printed by
> > filters. E.g. detection filters are printing the information either in
> > the stderr using custom formats, this should really be converted to
> > something easier to consume (whatever formats for which you don't
> > need a custom parser).
> >
> > The metadata muxer also might benefit from using a text writer, to
> > avoid again the need for a custom parser, and probably there are more
> > use cases easy to spot.
> >
> > So at some point we want to make this API accessbile from the
> > libraries, that is to move them into libavutil. Again, it's fine to
> > expose this at the tools level first so we can experiment and refine
> > the interface before moving to a stable one.
> > _______________________________________________
> 
> Yes, I see quite a number use cases as well.
> It's still a work in progress, but I've set up a GitHub repo for
> documentation and as a place of interaction. It's not for ffmpeg code,
> but there are tests, examples and a documentation Wiki:
> 
> https://github.com/softworkz/ffmpeg_output_apis/wiki
> 
> (a number of things are still incomplete)
> 
> 
> I'm also exploring a way for self-printing the data schema for each use
> case. On the repo Wiki there are Entity-Relationship diagrams for the
> FFprobe and the Graphs schema. I'll follow up with more details..

Hi Stefano,

I've got everything in shape now in this repo I've also completed done the write-up on my experiment regarding schema self-printing: https://github.com/softworkz/ffmpeg_output_apis/wiki/Schema-Self-Printing

I'd be curious what you think about it (of course others as well).

Best,
sw




_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".