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

[Nicolas George]

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.

[emulating the following commands with AVOptions]
> > ffmpeg -f s16le -ar 48000 -c 1 input.raw ...
> > ffmpeg -f video4linux -s 640x480 -r 14 /dev/video0
> ohh yes it could, please RTFS

I just RTFS again, and I am pretty sure this can not be done. See at the end
of this mail my analysis of the code to prove my point.

But it all boils down to one thing: AVOption in its current state can only
act on the file after it has been opened, while the interface I am
advocating needs to take place before the file is opened.

Furthermore, even if AVOption could emulate all necessary options, a lot of
programs do not implement any AVOption passing from the user, and will
continue so, just because it is not necessary to make the program work. One
can argue that these programs are wrong, but the one who suffer from it are
the user. Furthermore, the code to pass the options from the user is code
duplicated in all programs that implement it.

Let me say it another way: the AVOption infrastructure is very good for
ambitious programs that try to be self-documenting, including programs with
a GUI. But for simple programs that just want to read an audio-video file,
collecting options from the user and passing them to the library requires
some significant piece of code; it would be much more comfortable to let
av_open_input_file take care of everything.

So here is my current proposal:

- Extend AVOption so it can set the important parameters it currently can
  not. I think this can be done without too much trouble.

- Implement the parameter parsing on top of the corresponding AVOption.

Regards,

-- 
  Nicolas George


Annex: why AVOption can not emulate the commands I evoked:

First, the -f option:

- In av_open_input_stream, the ptr argument is never changed, and it is
  dereferenced. Therefore, the value of the ptr argument is final when
  av_open_input_stream is called.

- In av_open_input_file, the ic_ptr is never used before the call to
  av_open_input_stream. In particular, it is not used to determine the value
  of the ptr argument.

- ic_ptr is the only AVClass argument to av_open_input_file, and therefore
  the only one on which AVOption can have effect.

- Furthermore, the iformat field of the AVFormatContext is never changed
  after the opening, and there is no AVOption declared for it that could
  allow to change it.

Conclusion: the -f option can not be implemented on top of the AVOption API
in its current state.

Second, the -ar and -ac options:

I concede that AVOption _can_ change the sample rate and channels count. But
it can only do it after the file has been opened and the streams have been
detected. Unfortunately, for raw PCM streams, the stream detection crash
with a division by 0 if the channels count has not already been set.

Third, the -s and -r options:

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.

Furthermore, there is no AVOption for AVCodecContext that affects the
time_base, width or height fields.
-------------- 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/f01034c8/attachment.pgp>