[FFmpeg-devel] [FFmpeg-cvslog] xcbgrab: XCB-based screen capture

compn tempn at mi.rr.com
Tue Oct 28 16:05:39 CET 2014


On Tue, 28 Oct 2014 12:48:43 +0100
Michael Niedermayer <michaelni at gmx.at> wrote:

> On Tue, Oct 28, 2014 at 10:05:29AM +0100, Nicolas George wrote:
> > Le sextidi 6 brumaire, an CCXXIII, compn a écrit :
> > > so its name is changed in the makefile, but not the device name?
> [...]
> > Therefore, I think it is logical to have both devices called
> > "x11grab", i.e. "grab from an X11 server".
> > 
> > The same goes whenever there are several feature-equivalent
> > implementations for the same thing: you do not have both
> > httpopenssl:// and httpgnutls://, you just have https:// using one
> > of the library internally.
> 
> this makes it impossible to switch between them without recompiling
> though
> 
> for development and testing it may be usefull to enable both though
> 
> one example are fate clients, which if these parts are mutually
> exclusive potentially wont compile test both or if they can be
> enabled at build time one wouldnt be able to select which to use at
> runtime as their names equal
> 
> we maybe should introduce in addition to the default https & x11grab
> a x11grab_xcb and x11grab_x11 or something like that

is it the goal of ffmpeg to have multiple implementations of different
features?

ffmpeg can be compiled with native rtmp or librtmp. can we
compile both and switch between them? like -network native or -network
librtmp ?

same with codecs, for example xvid decoding vs native?
demuxers, such as gpac, mp4box or mkvtoolsnix vs native?
encoders are already ok by having different encoder names.

i dont mind. mplayer has this , by using native network or ffmpeg://
code. or -demuxer lavf or codecs by changing codec names around. iirc
vlc has similar options.

-compn


More information about the ffmpeg-devel mailing list