Re: videodevX incomaptability with avifile

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



James Sleeman wrote:
> 
> Hi all,
>         went to recompile avifile after updating to videodevX + bttv2, but
> there seems to be an incompatability with videodevX causing capture
> utilities (qtvidcap in the distribution (which, BTW needs some GUI
> touchups to enable window expanding when fonts are larger (especially
> notebook tabs need to expand when window made larger) than expected),
> and vcr also) seems the fourcc macro now takes four arguments...
> 
> Here is the attempted compile of qtvidcap...
> 
> Making all in qtvidcap
> make[2]: Entering directory `/usr/home/boffin/avifile-0.53.2/samples/qtvi
> cap'
> c++ -DHAVE_CONFIG_H -I. -I. -I../../include   -g  -march=i586
> -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include/SDL
> -D_REENTRANT -w  -I../../include -I/usr/X11R6/include
> -I/usr/local/qt-2.2.3/include -I/usr/local/include
> -I/usr/local/include/SDL -D_REENTRANT -c capproc.cpp
> In file included from ../../include/videodecoder.h:20,
>                  from ../../include/avifile.h:16,
>                  from capproc.cpp:4:
> ../../include/infotypes.h:50: macro `fourcc' used with just one arg
> make[2]: *** [capproc.o] Error 1
> make[2]: Leaving directory `/usr/home/boffin/avifile-0.53.2/samples/qtvid
> ap'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/home/boffin/avifile-0.53.2/samples'
> make: *** [all-recursive] Error 1
> 
> And here is the offending macro from the new videodev.h (from
> videodevX)...
> 
> #define fourcc(a,b,c,d)\
>         (((__u32)(a)<<0)|((__u32)(b)<<8)|((__u32)(c)<<16)|((__u32)(d)<<24
> )
> 
> Also sending this message to the Avifile mailing list.

The bug is fixed in the latest videodevX
(http://bttv-v4l2.sourceforge.net).  Please note, however, that qtvidcap
has broken v4l1 support, and while it works with bttv, it does not work
with the v4l1 compatibility layer in videodevX.

Anyone up to the challenge of porting this to v4l2?  It would require
quite an architecture change - the v4l2 stuff would have to be tightly
coupled to capproc.cpp to make best use of the buffering/timestamping
features of v4l2, but should give quite a performance boost.

-justin





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux