[FFmpeg-devel] x11 output device for libavdevice
Stefano Sabatini
stefasab at gmail.com
Sun May 26 14:36:51 CEST 2013
On date Sunday 2013-05-26 10:41:36 +0000, Carl Eugen Hoyos encoded:
> Stefano Sabatini <stefasab <at> gmail.com> writes:
>
> > On date Tuesday 2013-05-14 17:16:34 +0000, Carl Eugen Hoyos encoded:
> > > Stefano Sabatini <stefasab <at> gmail.com> writes:
> > >
> > > > + --enable-xv enable Xv video display [no]
> > >
> > > Imo, this should be autodetected.
> > > (Why should it be handled differently from alsa?)
> >
> > Because right now the build system is schizofrenic,
> > and it is not clear when autodetection logic should
> > be used or not.
>
> (Imo, it is crystal-clear, but that is not the quesion.)
It is not clear at all to me. What is the principle? Where is it
documented?
>
> > In most cases the user is *required* to explicitly
> > specify all the libraries she wants to use (and the
> > configure script will complain&fail in case the
> > library is not detected). To my eyes libxv is no
> > exception.
>
> So allow me to repeat my question:
> How is xv different from alsa?
The ALSA wrapper depends on the libasound library, which in turn can
be installed only when some features are available on the system.
The XV wrapper depends on the libXv library, which in turn can be
installed only when some features are available on the system.
So from this point of view I see no differences.
We sometimes apply the principle:
enable a feature if all its required components have been explicitly enabled and are available
and in other cases this other one:
enable a feature if all its required components are available on the system
> And imo, they are both *very* different from libx264,
> libm3lame, libdirac and libtheora (etc.).
Why and how?
>
> > Ideally we should be able to set the autodetection
> > policy, for example to automatically enable all the
> > available libraries/features.
>
> That may have been an interesting idea some years ago,
> now it sounds like a behaviour change that will
> produce many surprised users (which is why I am
> against such a change).
On the other hand the current system as is is inconsistent, confusing
and undocumented, and thus surprising even for a veteran developer.
--
FFmpeg = Fierce and Free Mythic Political Epic Geek
More information about the ffmpeg-devel
mailing list