[FFmpeg-devel] Notes about avdevice
donmoir at comcast.net
Sun Nov 25 16:41:28 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.
'It' would be the thing we are talking about and that is getting the devices and their resolutions in a reasonalble way. The reason
I said it would be easy is because you do already list the devices. For dshow it's a small step to get the resolutions and I will
post that code. For other than dshow I don't know.
> That was exactly what I was complaining about, did you have to add the "listen to reason" part?
No I did not have to add the 'listen to reason part'. Like all of you I get tense at times and not immune.
> I have offered a quick fix (parsing av_log, which I don't think is quite as bad as you claim, but clearly ugly)
I already have a better fix then the looking at av_log and thats just not a reasonable thing to do.
> 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.
Yes I agree.
The funny thing is when I see a programmer use IMHO... Not sure when I have ever met a humble programmer and if you are a humble
programmer then that would concern me :)
More information about the ffmpeg-devel