[FFmpeg-devel] [PATCH 5/5] src_movie: implement multiple outputs.

Nicolas George nicolas.george at normalesup.org
Sat Jul 28 17:56:08 CEST 2012

Le septidi 7 thermidor, an CCXX, Stefano Sabatini a écrit :
> There is a namespace problem (which occurrs in ffmpeg as well).

Your mail is strange, it looks like an old version is concatenated with a
newer one. If I am replying to the wrong version please correct me.

> Currently we have the following namespaces/contexts:
> - filters (can be assumed to be the first context to be looked for, if
>   the namespace is not specified)
> - formats (just one format in case of the movie, so there is no
>   ambiguity)
> - streams/codecs: there are multiple of them, so the stream specifier
>   is required for distinguishing between them
> - protocols, bitstream filters, etc.: currently not implemented but
>   it's not unlikely that we'll need to add options for them

Actually, Michael implemented a custom syntax to add protocol-level options.

> In case the namespace is not specified, we can establish a pre-defined
> look-up order (e.g.: filter, format, stream starting from the first
> one).

I agree with more or less all you wrote, but I think this problem is only
theoretical. There are very few decoders options, it should be quite easy to
ensure they do not clash with any other options. And it would certainly be a
good policy anyway, if only to avoid confusing users.

> It should be possible to extend the current API and use a notation
> which allows to specify the namespace in the way I proposed (or the
> equivalent which addresses the namespacing problem). This may be prove
> to be useful also for the other components/tools.

I believe the stream specifier syntax should prove enough if the lookup
order is correct: 'foo' will be recognized by the format while 'foo:' will
match all streams but will not be recognized by the format. All we have to
do is make sure the movie options do not clash with any format option.

> An alternative (orthogonal) approach for simplifying the syntax would be to adopt
> the notation used for filters/writers, e.g.
> f='rawvideo=video_size=pal:framerate=25'
> or
> -f rawvideo=video_size=pal:framerate=25 

This syntax does not look ugly, but I still would prefer if the users were
not required to know these subtleties unless they absolutely need to.


  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120728/dd1e65a8/attachment.asc>

More information about the ffmpeg-devel mailing list