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

Lukasz Marek lukasz.m.luki at gmail.com
Thu Feb 6 13:06:03 CET 2014

On 06.02.2014 03:57, Don Moir wrote:
> ----- Original Message ----- From: "Don Moir" <donmoir at comcast.net>
> To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
> Sent: Wednesday, February 05, 2014 7:18 PM
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] lavd: add device capabilities API
>> ----- Original Message ----- From: "Lukasz Marek"
>> <lukasz.m.luki at gmail.com>
>> To: <ffmpeg-devel at ffmpeg.org>
>> Sent: Wednesday, February 05, 2014 6:59 PM
>> Subject: Re: [FFmpeg-devel] [PATCH 2/4] lavd: add device capabilities API
>>>>>> 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
>>> documentation)
>>> "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.
>> It probably can be met for any true hardware device which is what I am
>> interested in. SDL and OpenGL and the like, to me fall more in the
>> line of applications issues.
>>> Basically the resulting structure would need to be more complex,
>> Better to have a more complex structure than to have a complex
>> interface to it. Probably leads to less usage of the thing you are
>> spending time on.
> Might be good to separate this out some to simplify it. A lot of people
> are interested in knowing only about capture devices and could care less
> about things like SDL and OpenGL in ffmpeg.
> Could be a simple interface for ennumerating capture devices. Like I
> said before, you don't really want to walk thru the ennumeration
> possibly several times for some devices. The ennumeration can cause load
> and unload of resources and you never know what a device might be
> initializing. Some do this quickly and some slowly.

Solution you suggest is the same I proposed before and was rejected.
So I give up any further work on it until you figure out what should it 
look like.

Best Regards,
Lukasz Marek

You can avoid reality, but you cannot avoid the consequences of avoiding 
reality. - Ayn Rand

More information about the ffmpeg-devel mailing list