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

[Don Moir]

----- 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.