[FFmpeg-devel] Notes about avdevice
Reimar.Doeffinger at gmx.de
Sun Nov 25 16:05:23 CET 2012
On 25 Nov 2012, at 14:12, "Don Moir" <donmoir at comcast.net> wrote:
> On Sun, Nov 25, 2012 at 01:47:37PM +0100, Reimar Döffinger wrote:
>> On Sun, Nov 25, 2012 at 07:20:00AM -0500, Don Moir wrote:
>> > >On Sun, Nov 25, 2012 at 03:38:20AM -0500, Don Moir wrote:
>> > >>>Don Moir <donmoir <at> comcast.net> writes:
>> > Cameras
>> > get plugged in and unplugged and would need to update list
>> > periodically. I am not going to do something like try to read the
>> > av_log just so I can use avdevice. But getting the list in a modern
>> > way is easy along with the device resolutions and should be
>> > implemented in a modern way instead of something that goes back 30
>> > years.
>> If it's so easy then design and propose an API. Hyperbole just
>> pisses people off and doesn't get anything done.
>> My suggestion would be to think if the avoption stuff could be extended
>> to query valid option values even for more complex options like a
>> device parameter.
>> Thats an interresting idea
> I am not here to piss anyone off. I already have it implemented and if you want that code I will give it. I don't have the time to go thru all the details of putting it into ffmpeg.
It would help to know what the "it" you have implemented is exactly. Or just send what you have.
Code to list the devices exist already after all, just not a convenient way to use the result programmatically.
> If you don't want it or don't care and don't want to listen to reason, then don't.
That was exactly what I was complaining about, did you have to add the "listen to reason" part?
I have offered a quick fix (parsing av_log, which I don't think is quite as bad as you claim, but clearly ugly) and a high-effort one that also needs more design work but that we should be able to re-use for almost anything. That doesn't preclude other solutions though.
More information about the ffmpeg-devel