Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#9683 closed enhancement (invalid)

New multimedia filter(s) which can output to a file

Reported by: ScriptTiger Owned by:
Priority: wish Component: ffmpeg
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the wish:
Currently, using the movie and amovie filters allow you to define multimedia sources directly in a filtergraph. However, there are currently no counterpart filters to allow you to output to a file, which must be done via additional trailing command-line parameters (i.e. "-map", "-c:a", "-c:v", etc.)

I propose (a) new multimedia filter(s) for writing to output files which are defined directly in a filtergraph.

The use case for this is that all terminal environments, especially on Windows systems, are extremely limited in multiple ways. The solution to avoiding these limitations is to use the "-filter_complex_script" parameter and offload the filtergraph into an external file which can be read directly by FFmpeg and bypasses the terminal limitations. However, having to separately map the outputs outside of the filtergraph script is a single point of failure which can possibly undermine the advantages of using an external filtergraph script in cases where there are a large number of outputs, each requiring separate mappings, codecs, and containing varying path lengths that can quickly hit the terminal limitations for large, complex projects.

I think ultimately having such a filter will also make FFmpeg much more scalable to large, complex projects, as well as make filtergraphs themselves much more portable as a kind of project file which contains all the information needed to output any project, thus making additional command-line parameters redundant in cases where the filtergraph script can also define output multimedia files.

The intention of this is not to look negatively upon the currently available command-line parameters, as they definitely give you a lot of options and make working with FFmpeg extremely fast and efficient under any circumstance. However, for very large, complex projects, being able to contain everything to a filtergraph would definitely improve usability and efficiency for those use cases.

A common example of a use case would be one of "big data" visualizations, where you have multiple multimedia sources and need to perform highly complex transformations with very large filtergraphs and output that data in multiple formats. Currently, the only way to do this is by creating multiple filtergraph scripts that deal with only a smaller subset of the data at a time and running FFmpeg multiple times, doing just a small group of outputs at a time, and spending an order of magnitude more time than necessary on redundant transformations. This also makes those filtergraphs not very portable since each filtergraph requires their own additional command-line parameters to define their outputs, like mappings, codecs, etc. So, just making the filtergraph script itself have the ability to be self-contained seems like it would massively improve workflow efficiency, portability, scalability, and just overall simplify things a lot.

Change History (2)

comment:1 by Elon Musk, 2 years ago

Resolution: invalid
Status: newclosed

Use library. ffmpeg command only application is not solution to fit all use cases. Adding another encoder/muxer filter is not going to happen because it would not make thing any more easier that currently are.

in reply to:  1 comment:2 by ScriptTiger, 2 years ago

Replying to Elon Musk:

Use library. ffmpeg command only application is not solution to fit all use cases. Adding another encoder/muxer filter is not going to happen because it would not make thing any more easier that currently are.

Thanks for your feedback! I definitely agree using the library is definitely the most efficient way to solve this, although it would require a bit more upfront work for each project to code everything. When I see the movie and amovie filters, it just seems as though the filtergraph script is only a couple filters shy of being able to be completely self-contained though, so I thought maybe it would be an obvious design goal and easy fix. Thanks anyway! You guys are still awesome!

Note: See TracTickets for help on using tickets.