[FFmpeg-devel] Notes about avdevice

Reimar Döffinger Reimar.Doeffinger at gmx.de
Sun Nov 25 13:47:37 CET 2012


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:
> >>>
> >>>>1) avdevice has dependencies on avfilter and swresample.
> >>>>I have no need for either of these and this is
> >>>>unfortunate. It doesn't appear that these dependencies
> >>>>can be turned off.
> >>>
> >>>Unreproducible.
> >>>
> >>>Carl Eugen
> >>
> >>If I try to use avdevice without avfilter-3.dll and swresample-0.dll
> >>in place it complains. This is possibly due to lavfi.c in avdevice.
> >
> >The swresample dependency is because you have e.g. scale filter enabled
> >in avfilter.
> >The avfilter dependency is because you have the avfilter indev
> >activated.
> 
> How do you build avdevice with no dependency on avfilter ?

I really think you are quite capable of figuring out yourself, but look
at the --list-indevs and --disable-indev configure options (something
like --disable-indev=lavfi).

> >Also the device lists do _not_ go to stdout, they go to av_log.
> >While hardly convenient, intercepting them certainly is feasible.
> 
> Yes correct and basically means the same thing to me and not
> useable. You never know what will come thru av_log and in my case I
> might have several videos playing along with camera support.

There is a context parameter, reliably filtering out the messages
from (a specific) avdevice is not such a huge issue.

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


More information about the ffmpeg-devel mailing list