[FFmpeg-devel] [PATCH 5/8] lavd: add device capabilities API

[Michael Niedermayer]

On Sat, Apr 05, 2014 at 10:17:33PM +0200, Lukasz Marek wrote:
> On 05.04.2014 05:15, Michael Niedermayer wrote:
> >>I think we have to distinguish input and output devices.
> >>I designed it having mostly output devices in mind and it is not
> >>optimal for input devices. Things you point are 100% true for input
> >>devices and hardly true for output devices.
> >>
> >
> >>Probably any output device has an option that user want to query.
> >>Output devices doesn't have options like codec, format, frame_size
> >
> >thinking of a output device like a TV set, it would have limits on
> >what resolution and framerate it can display.
> >codecs would be even more limited and might be just raw or might
> >support 1 or 2 compressed formats.
> >
> >
> >
> >
> >>etc because they take them from provided stream. User want to query
> >>them to make sure they provide correct stream. I wanted to avoid
> >>adding these options to device's option list because they are only
> >>useful during probing, not during normal use of the device. When
> >>such options appears on the list, they may confuse the user (for
> >>example when they list options using av_opt_next() function)
> >>
> >>For input devices everything is opposite. Probably all devices have
> >>the same options already on its options list, so your remarks are
> >>OK.
> >>
> >>I think it would be good to implement it different for input and
> >>output devices (I don't mean separate API, but rather different
> >>approach when implementing the device). input devices would use its
> >>own options, output devices would use the structure I added and hide
> >>its options from user.
> >>
> >>I just don't know how to implement it yet.
> >>Maybe additional flag for av_opt_query_ranges to mark that
> >>capabilities are queried, other function I already mentioned in
> >>previous email, or resign from hiding dummy options. I dont like
> >>these dummy options visible tho.
> >
> >a AV_OPT_FLAG_ could be added to mark them as for capability
> >querrying
> >or we could even consider to querry the AVCodecContext from an
> >AVStream instead of the capabilities struct but iam not sure where
> >this would lead to implementation wise
> 
> I slept it over and there is a still a problem with aliasing
> existing options (of input devices) with dummy options for querying.
> Input device after allocating context have them initialized with
> default values. By design querying capabilities will return results
> limited by set values. So it would always return just one set of
> values equal to device's defaults.
> 
> I still think this there should be separate struct to store them in
> both cases.
> It can be moved to AVFormatContext to simplify API, but avformat
> need to know size of the structure. It is avdevice specific so I
> don't know if moving it to avformat is good idea. I can add alloc
> function in libavdevice, but it will create dependency.
> I don't know if it all is worth removing 2 simple API calls.

well, if people are happy with how it is with teh 2 calls, i dont mind



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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140405/13c7d086/attachment.asc>