[FFmpeg-devel] RFC: setting format parameters from the URL

[Michael Niedermayer]

On Thu, Apr 10, 2008 at 07:58:16PM +0200, Nicolas George wrote:
> Le decadi 20 germinal, an CCXVI, Michael Niedermayer a ?crit?:
> > Patches documenting it are welcome, patches reimplementing the functionality
> > are not.
> 
> You are of course right, and all my thanks go to Stefano for his documenting
> patch.
> 
> As for me, I am amending my position to take the existence of AVOption into
> account, but I do not think it is quite enough.
> 
> > That is because ffmpeg has the various AV* structures deeply intermingled into
> > its code. These are not related to AVOptions at all, your string would need
> > all that mess and more as well.
> 
> That is precisely the point, isn't it? If any program that wants to read
> audio-video files needs "all that mess", then its place is in a library.

The point is that the mess results from ffmpeg.c design, not from AVOption
and would not be less if another system was used. Actually i do not even know
how your system could do what AVOption does.


[...]
> 
> Annex: why AVOption can not emulate the commands I evoked:
> 
> First, the -f option:

The -f option selects the format it has somewhat a special status


[...]

> Second, the -ar and -ac options:
[...]
> Third, the -s and -r options:

Well it will likely surprise you but we really do not support these options
through AVOption prior to opening the file currently. We are missing a 5 line
change (mostly removing stuff from the deprecated AVFormatParameters).
You can take a look at video_codec_id and audio_codec_id as examples on
how AVOption can set parameters before opening the file.


> 
> The video4linux pseudo-demuxer requires that the image size and frame rate
> are set in the AVFormatParameters, but the AVFormatParameters is not an
> AVClass object.

AVFormatParameters is deprecated and will be removed as soon as the
functionality has been moved elsewhere and we bump the major ver.


> 
> Furthermore, there is no AVOption for AVCodecContext that affects the
> time_base, width or height fields.

no, do you also want to invent a new API for them or 3 seperate APIs
one for each variable?

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080410/03626f14/attachment.pgp>