[FFmpeg-devel] RFC: setting format parameters from the URL
Sun Apr 13 15:18:15 CEST 2008
Le duodi 22 germinal, an CCXVI, Michael Niedermayer a ?crit?:
> No but I have difficulty imaging a program which uses any libs directly but
> is not capable to iterate over the tokens of a string.
> Code which wants to pass a single string can call ffmpeg, code which
> wants to use libav* splits that string in tokens (by , " " ; whatever)
> and passes them to av_set_string().
> Of course that does need a few bug fixes so it works for the 4 options
> you complained about similarly would your new 1 string API.
> What you want is that we provide a way so that you can pass options to
> lav* behind all applications and libs, that is as part of a filename.
> Fix the app!
I think we are thinking about completely different types of applications.
The applications I am especially thinking of with this proposal are simple
command line tools that perform some simple and very specialized task on
audio or video files, like doing some statistics, extracting some data, etc.
An example of such an app is ffprobe; I have recently written a tool to plot
the audio spectrum of a file; I am about to start writing a tool to
synchronize two files with the same audio.
There are a lot of similar tools, and probably much more are developed as
quick hacks and never released to the community.
These tools take a filename, read the corresponding file, and act on the
decoded result. They can not call ffmpeg externally, since they often need
the properties of the file (bitrate, channels, etc.).
From the user's point of view, the more formats these tools are able to
handle, the better, obviously.
But I think that adding to such tools code to set format parameters is a
waste of programmer time.
It is also a waste of user time/memory, since even if these tools implement
a way to set format parameters, they will all adopt a slightly different
Therefore, providing a common syntax to set these parameters is helpful both
to the programmers and the users of such tools.
Of course, it is useless to GUI apps, to apps which already have a full
option system, etc. But neither does it any harm.
And after all, what I suggest is only a small enhancement to the principle
of trying the wave demuxer when the filename ends with .wav.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel