[FFmpeg-devel] [PATCH 1/4] lavf: add probe device API

[Lukasz M]

>
>
> > I attached another draft. This base on AVOption API and it seems to
> > be good direction. Please have a look on it, just want to make sure
> > I do what you had in mind. I made some dummy implementation for
> > opengl device and simple test app.
> >
>
> > In simple words I added new AVOption struct that should be used as
> > nested structure to device private context structure. It is very
> > convenient all devices have the same names of the params. The only
> > disadvantage of this are options that may get duplicated with
> > already existing options. Input devices probably provide most of
> > them, but output devices usually take them from the stream. I'm not
> > sure it can cause some problems. Some method to link them would be
> > nice.
>
> you mean something like "w" and "width" ?
> they should both point to the same index in the structure and be
> one after the other in a AVOption array, so detecting them shouldnt
> be hard.
>

Yes, it is something like that, but a small difference they use different
structures.
Example:

struct SomeDeviceContext may have field "int w" and option "w"
struct AVDeviceCablities used as nested struct have "int width" and option
"width"

As they point indexes int different structures. It would be nice "w" param
can be "redirected" to "width" field in nested struct.
Unless I missed something it is not possible. One solution I can think of
is using option set callback described below.
Renaming


>
> > maybe AVClass can be extended by following callbacks:
> > - option set - device may get informed duplicated value is changed
> > and copy value of duplicated param to second one)
>
> > - validation - device (or any other class in fact) may validate new
> > value before it is set. av_opt_set* would return AVERROR(EINVAL) if
> > rejected by device.
>
> this could make sense, yes
>

You refer to validation only, or both. I think both may be useful in
general.



> >
> >
> > Other problem I notice there is no way to free nested structure.
> > Following code will leave a leak:
> >
>
> > avformat_alloc_output_context2(&oc, NULL, device_name, NULL);
> > av_opt_set_int(oc->priv_data, "width", 100, AV_OPT_SEARCH_CHILDREN);
> > avformat_free_context(oc);
>
> normally after allocating a output context one would use it, in
> which case the private structure gets freed by the muxers code at the
> end (the muxer would also potentially put all kinds of other
> allocated things in its private structure that it has to free at the
> end)
>
> the obvious solution would be to free it in avformat_free_context()
> this would need to be tested though
>

I thought about av_free_opt_with_childeren or av_free_opt2 with flag param,
but I will check if av_format_free_context() may handle it.


> > +int test_video_configuration(void *device_class)
> > +{
> > +    AVOptionRanges *ranges;
> > +
> > +    //print_options(device_class);
> > +
> > +    av_opt_query_ranges(&ranges, device_class, "width",
> AV_OPT_SEARCH_CHILDREN);
> > +    print_ranges(device_class, ranges, "width");
> > +    av_opt_freep_ranges(&ranges);
> > +    av_opt_query_ranges(&ranges, device_class, "height",
> AV_OPT_SEARCH_CHILDREN);
> > +    print_ranges(device_class, ranges, "height");
> > +    av_opt_freep_ranges(&ranges);
>
> AV_OPT_TYPE_IMAGE_SIZE might allow these 2 to be printed as pairs
> somehow, which probably is a more natural representation
>

I did think to make it as image size, but it assumes there is no
correlation between max width and height