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

[Michael Niedermayer]

On Thu, Apr 10, 2008 at 09:00:52PM +0200, Michael Niedermayer wrote:
> 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.

After looking at the code, i realize that the 2 are not set via AVOption,
but they could
Yes not everything has been moved to AVOption, and some things need a change
here or there for it to work. This is no reason though to come up with a
extreemly limited and hackish API to pass the parameters through the backdoor.

AVOptions allows you to read and write parameters from structures,
your system does not.
AVOptions allows you to list/enumerate available options, your system
does not.
AVOptions provide max/min/default/helptext for each option, your system
does not.
Your system is passing an opaque string. How should a GUI support that?
Or anything but a command line tool?
How and where is this string parsed? Why on earth should we use a seperate
system to pass the very same parameters (size/channels/sample rate/...)!?
Before the file with your weird string and afterwards with AVOptions.


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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- 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/304dc359/attachment.pgp>