[FFmpeg-devel] [PATCH 4/4] examples: adding device_get_capabilities example

Diederick C. Niehorster dcnieho at gmail.com
Sat Jun 5 16:33:11 EEST 2021


On Sat, Jun 5, 2021 at 2:41 PM Andreas Rheinhardt
<andreas.rheinhardt at outlook.com> wrote:
>
> Have you looked at
> 2ff40b98ecbd9befadddc8fe665a391f99bfca32/0a071f7124beaf0929f772a8618ac1b6c17b0222?

I have, but didn't know what to do with it. Are you suggesting
reverting part of those two commits? The bit of documentation of the
API (lines 334--402) of avdevice.h suggest it was the intention for
the API to work with an allocated, but not opened, input or output
context and at the time that was written, it was possible to create
either. Now, as you know, input formats can only be directly opened
and created. It seems the removed flag and such you are referring to
in the commits had another use, and i don't see that a new flag is
needed. If i would implement something like
avformat_alloc_input_context, we:
1. would again be able to make allocated but unopened iformats
(admittedly for the very small use case of using this API, but at no
cost if used in other cases
2. would only need to make small changes to avformat_open_input (don't
set url if input NULL, else overwrite??; don't allocate priv_data if
already set; think thats it)
So no need for adding a flag, or reintroducing demuxer_open or so, i think.

> > [...]
> >
> Of course you can propose all sorts of API extensions; but don't be too
> beholden to the current API. It has never been tested in practice and it
> shows (e.g. it is built on top of the AVOptionRanges API which is quite
> underdocumented (see the remark/gotcha about the AVOptionRange structs
> not being individually allocated for your patch 3/4); and making each
> query_range callback allocate an AVOptionRange unnecessarily ties
> sizeof(AVOptionRange) to the ABI -- I don't get why this has been done).
> Also what you are experiencing here shows that there probably never was
> a working example.

Yes, I had trouble wrapping my head around the AVOptionRanges API, the
only usage example i found was av_opt_query_ranges_default() in
libavutil/opt.c and regarding the gotcha, it seems i
misread/misunderstood something of what i read there. Do you think
making sizeof(AVOptionRange) part of the public ABI is something to
fix / can it still be fixed?

> Besides that, there are more weird things: Why is
> AVDeviceCapabilitiesQuery a public struct and not an opaque one if it is
> not to be used? Why is av_device_capabilities public if it should not be
> used by a user?

Lets clean it up. And since it hasn't been used yet, i guess i can do
so without deprecations for either?
Just to check, you are suggesting the following, correct?
1. from avdevice.h, remove typedef struct AVDeviceCapabilitiesQuery
and extern const AVOption av_device_capabilities[];
2. change to avdevice_capabilities_create and
avdevice_capabilities_free signatures to taking **void as first input
3. remove forward declare of struct AVDeviceCapabilitiesQuery; from avformat.h
4. change signature of create_device_capabilities and
free_device_capabilities to taking *void as second argument

Thanks and all the best,
Dee


More information about the ffmpeg-devel mailing list