[FFmpeg-devel] [PATCH 2/4] lavd: add device capabilities API

Lukasz Marek lukasz.m.luki at gmail.com
Thu Feb 6 00:59:37 CET 2014

>>> Hi Lukasz,
>>> I am not sure about your device list API.
>>> You have:
>>> typedef struct AVDeviceInfoList {
>>>     AVDeviceInfo *devices;               /**< list of autodetected
>>> devices */
>>>     int nb_devices;                      /**< number of autodetected
>>> devices */
>>>     int default_device;                  /**< index of default device */
>>> } AVDeviceInfoList;
>>> int avdevice_list_devices(struct AVFormatContext *s, AVDeviceInfoList
>>> **device_list);
>>> Not sure why I would need an AVFormatContext but I may missing something
>>> there.
>> To get dev cap you need context for options for example. In
>> implementation you need to "open" device to check if configuration is
>> really working or list properties ranges. For example pulse audio
>> allows to play on remote server. You need to know that user wants to
>> test remote server and its done by device options.
>>> Just not exactly clear so this is just what makes the most sense to me.
>>> 1)  in avdevice_list_devices,  identify type of video and or audio
>>> devices.
>> Make sure you distinguish device at lavd level (pulseaudio, alsa, oss
>> for audio and fbdev, xv, opengl, sdl for video) and device names for
>> each of them (sound outputs, sound cards etc).
>> This function list the second ones for given lavd device. Maybe
>> function name should be changed to not confuse.
>>> 2)  Provide a list and their capabilites at same time. So maybe:
>>> typedef struct AVDeviceInfo {
>>>     char *device_name;                   /**< device name, format
>>> depends on device */
>>>     char *device_description;            /**< human friendly name */
>>>     // either list or count
>>>     int  n_capabilities;
>>>    AVDeviceCapabilities *capabilities;
>>> } AVDeviceInfo;
>>> I know you have ways of doing it, but it seems akward at best and then
>>> more work to first find devices and then lookup capabilities for each
>>> deivce. I see I must init something to get capabilities as well so just
>>> don't see how that falls in line well.
>> It was already discussed. I started with something similar, but
>> unfortunately it is not suitable for all cases. You cannot just return
>> list of capabilities because they can interact with each other and
>> they may differ for each device name.
> I guess I don't understand how devices interact with each other.

not devices interact with each other, but caps of the device. When you 
set one param, it may affect others.

> Each device I know of have unique names and capabilites. Could be audio and
> or video. I don't consider Opengl and SDL to be true devices is that is
> where you are coming from.

I don't know what you mean by "true devices". Yes, opengl nor SDL are 
not a hardware, but they are "devices" that do that (quote from 
"The libavdevice library provides the same interface as libavformat. 
Namely, an input device is considered like a demuxer, and an output 
device like a muxer, and the interface and generic device options are 
the same provided by libavformat (see the ffmpeg-formats manual)."

>> The simple flow I see for video output is:
>> pick lavd device.
>> list device names.
>> pick device name
>> start cap query
>> set frame_width/height
>> query codecs
>> set codec
>> query formats
>> set valid format in filterchain sink
>> finish cap queries
>> And I don't think it is too much complicated.
> I am developing for windows and then mac. So for windows interested in
> dshow devices. Currently, I enumerate the devices, names and their
> capabilites in one step rather than the 10 steps you suggest. During the
> enumeration of the devices I am there so good to get the capabilites in
> one step. It appears that your steps may cause the dshow code in ffmpeg
> to go thru the same code multiple times. There is no need to set a frame
> width / height to query the formats as this is all in the same structure
> for dshow at least.

You put example of dshow, but I don't want to make interface for 
supporting dshow, but generic one, for all already implemented and 
future devs.
In many cases it would be possible to return all at once, yes, but it is 
assumption that can be not met at some point.

Basically the resulting structure would need to be more complex, in case 
you want to get all possible configuration at once and Michael suggested 
to use AVOption API becuase it solves all these issues

You may read this thread, because it is where this idea started

Best Regards,
Lukasz Marek

Royale with Cheese.

More information about the ffmpeg-devel mailing list