Leon Zadorin wrote the following: FOR THOSE WHO DO NOT WANT TO READ THE REST OF THE README FILES (in ag-media and in ag-media/vic - although they shall do so at THEIR OWN RISK) here is an extremely short "howto": The dependencies to build vic include libXv-devel (and possibly libGL-devel) so, for example, on fedora, one would do # yum install libXv-devel Also, now the openssl development libraries are needed for building the software (e.g. libssl-dev). Depending on X server installed, etc. you may also need to install the xorg-devel libraries... (otherwise the ./configure will fail with "can't find X11 headers"). For users who want to capture and send DV/HDV video streams (e.g. from firewire camera) on Linux, the development version of "libiec61883" needs to be installed first. Otherwise, use the "./configure" script with --with-vic-flags="--disable-iec61883" option (it will build vic without any firewire-grabbing capabilities thus removing the "libiec61883" dependency). Having satisfied all of the aforementioned dependencies, perform the following: ./configure make cd vic su ./setSystem eth0 tbf exit ./runDV 233.45.67.88/23456 When calling "./setSystem" script, the "eth0" should be the name for your network card device (e.g. as found in /dev/ directory). Please note that if you reboot your machine, then you will need to re-run the "setSystem" script - it was designed mostly for testing purposes and is not a replacement or an excuse for a correctly administered system (e.g. in terms of high-bandwidth deployment contexts). Feel free, however, to look inside the script and apply any of it's actions in the appropriate system configuration/administration areas (e.g. "rc.local" etc). The "runDV" script may be used with non-DV equipment (video-capturing devices) - it just sets various command-line options for vic (for more info on various options read the README* files as well as run "vic" without any command line options, e.g. cd vic; ./vic ). If you still have transmission issues (e.g. network drops packets all the time so that your frame-rate is reduced or the images are "messy") - use the "runDVslow" instead of "runDV" and/or edit the "setSystem" script and lower the value for a TBFRATE variable. Currently, the vic's code is compiled with full debugging (to aid for testing, etc.) However, one may try compiling the Ffmpeg (where the majority of DSP-intensive computations occur) with few opitmasation flags. To do so, instead of running "./configure" run something like: ./configure --with-ffmpeg-flags="--cpu=powerpc --tune=G4" You will need to know your cpu of course - but this might be of considerable use anyway, esp. when Ffmpeg is unable to determine the architecture-type by itself (e.g. Ffmpeg currently uses "uname -m" command to determine the architecture and NetBSD on macppc returns "macppc" string... which is not expected by Ffmpgeg in its configure script). For a full list of cpu and tune options see the Ffmpeg/Revision6182/configure file, but here are a few excerpts: For "--cpu" (pick only one of course): --cpu=powerpc --cpu=x86 --cpu=x86_64 --cpu=ia_64 For "--tune" (pick only one of course): --tune=G4 --tune=G5 --tune=i686 --tune=athlon --tune=opteron And, of course, if you want to 'stretch the limit' and just go crazy, you can always try something like this (replace cpu and tune with appropriate values for your machive as well as do experiment with limits in other options - such options will also depend on the version of GCC that you are using): ./configure --with-ffmpeg-flags='--extra-cflags="-funit-at-a-time -pipe -O6 -fno-rtti -ffast-math -funroll-loops -fexpensive-optimizations -fprefetch-loop-arrays -fno-math-errno -funsafe-math-optimizations -fno-trapping-math -fno-exceptions -Wall -fomit-frame-pointer -falign-functions -falign-jumps -fstrict-aliasing -fno-stack-limit -finline-limit=5000 -fstrength-reduce -floop-optimize --param inline-unit-growth=5000 --param large-function-growth=5000 -ftree-vectorize" --cpu=powerpc --tune=G4' Of course, Ffmpeg might override some of those (e.g. -O3 instlad of -O6... so if you are keen - see if it will be possible to overcome this somehow... e.g. I think the last option always overrides conflicting earlier options)... //--------------------------------------------------------------- HERE GOES THE REST OF THE RANTS :-) => to do a default build: ./configure make (on *BSD use gmake instead of make) Please note that the build does NOT cater for cross-compiling (e.g. it will use native system's endian orientation when building vic and other related sources). Also, please note that this "top-level" configure/make script combo is not designed for development purposes - only building the whole source-tree initially (e.g. after downloading). If incremental builds are needed - cd to a specific dir (e.g. cd vic/Makefile is designed to be suitable for development/incremental builds). ==> Currently only the linux-based systems have been catered for (this includes relevant configure.XXX changes). NetBSD is also fine, but Iec61883 files (firewire grabbers) are not available (currently) on any platform other than linux-based systems. => to do a default clean: make clean => If default build fails, then consider using ./configure with few important options: --disable-imlib2 allows to exclude the usage and build of imlib2 (for very old systems that do not have libfreetype, libjpeg, libpng) --with-ffmpeg-flags=args allows to pass extra options when configuring and building FFMPEG (sometimes it needs those as on systems which do not have memalign functions...) --with-custom-gcc=dirname allows to build using different GCC by prepending its path to PATH environment variable Example of the options: ./configure --disable-imlib2 --with-ffmpeg-flags=--enable-memalign-hack --with-custom-gcc=/home/leon/Gcc/Installed then type make For, example see "configureSpecificForLeon" script which configures the software on my NetBSD v3 box. => HTML documentation for vic (after being manually generated by cd vic and then ./doxygenRUN) is in vic/Doxygen/html/index.html so after opening the aforementioned index.html, follow the "Namespaces" link and VISLAB_at_UQ::Vic... etc. links. The main page (index.html) contains UML class diagram showing what I've written (in color), black'n'white boxes are from old vic which are included for a more comprehensive visualisation of the role and placement of the new code. => after a completed build, the vic binary should be located in the vic dir. => you can cd ./vic and then execute ./run script to use vic (read the README's in vic dir for more info on any of the runXXX scripts). ==> With this software package, some of the source-code files were written from scratch and some were modified. For the modified code: "leon was here" tag-phrase was used to indicate the changes (i.e. it should be reasonably stright forward to see what changes were done to the existing files). Moreover, one can do a diff on the original codebase which was used as the starting point for this software project (the tag-pharse usage was due to the fact that svn/cvs was not initally available and there was a need to "quickly" identify any of the modified files at a later stage when copying additional software licensing text - in a near future will (now that svn is used for the source-code management) take these phrases out... or may be someone else will do it for me :-) //------------------------------------------------------------------ Windoowze-specific info: Win port now supports transmission and reception of DV/HDV. Building steps: The port builds on mingw/msys (which I subjectively, incorrectly but with determination shall call minsys). These are the steps. From mingw (www.mingw.org) site (or referenced links): download and install mingw (e.g. mingw-5.1.3.exe to say c:\mingw or whatever the default happens to be); during installation tick/choose the "g++" component as well. download and install minsys (e.g. msys-1.0.10.exe and when it asks you for mingw location - specify it, say c:\mingw) download and install minsys developers kit (e.g. msysdtk-1.0.1.exe) download the latest bash (e.g. bash-3.1-msys-1.0.11-snapshot.tar.bz2). Uncompress it (if uncompressing/untarring from within minsys environment/shell, then exit all minsys shells afterwards). The contents of the uncompressed folder (e.g. all of the subfolders such as bin, doc, etc.) should be copied over the / of msys directory (e.g. c:\msys\1.0). Do not copy from within minsys environment, "drag'n'drop" all of the aforementioned folders the "windoooze" way. For building the openssl in mingw/minsys environment, the following notes might be of interest: Download the openssl sources (e.g. openssl-0.9.8d.tar.gz). Type "tar zxf openssl-0.9.8d.tar.gz" (do not worry if at the end there will be plenty of "cannot create symlink" messages... proceed anyway). Then, the following (albeit somewhat altered) steps have worked for me (from http://tor.eff.org/svn/trunk/doc/tor-win32-mingw-creation.txt): Type "cd ./openssl-0.9.8d/" Type "./Configure no-shared mingw" Edit Makefile and remove the "test:" and "tests:" sections. Type "rm -rf ./test" Type "cd crypto/" Type "find ./ -name "*.h" -exec cp {} ../include/openssl/ \;" Type "cd ../ssl/" Type "find ./ -name "*.h" -exec cp {} ../include/openssl/ \; Type "cd .." Type "cp *.h include/openssl/" Type "make" Type "make install" Further, you will need to set 2 environment variables (to point to the location of the installed openssl libraries and headers). One of the way to try and achieve this is to create ".profile" file in your minsys home directory (e.g. "/home/your_user_name/.profile"). Then edit the aforementioned file by adding the following: OPENSSL_LIB_PATH=/usr/local/ssl/lib OPENSSL_INCLUDE_PATH=/usr/local/ssl/include if [ -n "$LIBRARY_PATH" ] ; then LIBRARY_PATH=$LIBRARY_PATH:$OPENSSL_LIB_PATH else LIBRARY_PATH=$OPENSSL_LIB_PATH fi if [ -n "$CPATH" ] ; then CPATH=$CPATH:$OPENSSL_INCLUDE_PATH else CPATH=$OPENSSL_INCLUDE_PATH fi export LIBRARY_PATH CPATH then (re)start the minsys shell (i.e. if you were editing the .profile file from a shell - close the shell first, then double-click on the minsys icon...) and then cd to ag-media. All that is left is: ./configure make If you want to debug, download and install gdb (either from mingw or by installing cygwin - I use cygwin's debugger as the current one from mingw does not work for me...) In future, I am not certain what should be the default building evnironment (Ffmpeg does not like VisualStudio [and who can blame it], cygwin is rather nice because it has svn and its "managed" mounts allow for unix filenames [e.g. ending with dots, etc.])... I am here to "kick-start" the port, the actual "fully-fledged" development should probably be done by someone who actually cares-for/likes/respects windoooze... Usage tips: Command-line "-g" option is advised as it will make vic a little more responsive to user (e.g. system does not need to wait for VBlank's events from DirectDraw subsystem). If one wants to send DV/HDV, one should choose the device begining with "Iec61883UnfinishedMSHack" text (don't forget to set the port to "dv" in the transmission window). Swapping between DV and HDV appears to be a little convoluted in windooozz - one needs to quit vic (if running), power-cycle the camera, then start vic. Interlaced rendering is not (yet) supported on this port (i.e. currently will work only on Linux port (or any other Unix port which supports appopriate XVideo acceleration). Windows still needs to be studied in terms of "bursty network traffic smoothing". If bursty traffic is allowed by Windows box - then sending DV/HDV may be a problem (although one can try the "-e" a.k.a "cpu hogging" command-line option; such an option, however, will result in using a lot more CPU). In terms of "bursty traffic smoothing" there *may* be some 3rd party software which does the trick (but the chances are rather slim). For example, (and to help someone when/if they will be trying out some 3rd party network smoothing product), http://bandwidthcontroller.com offers a TrafficShaper product. It appears to install a kernel component which at least indicates a remote possibility that it may manage bursty traffic with a better timing resolution (e.g. finer or at least at a minimum of 1 kerner jiffy [interrupt-induced signal]). But there are at least 2 problems: the freeware version does not support UDP and standard edition has very small limits (for our type of application) on the overall internet traffic (24,576 kbps max uploading capacity). One may set the "full speed local network traffic" (in the overall "options..." drop-down menu) to include multicast addresses, but this does not appear to have any effect when creating individual rules (i.e. creating "unlimited" rule for UDP uploading still limits the speed to about 65kB(ytes)/sec). In short - there is still a large amount of research that needs to be done in relation to bursty network traffic smoothing in Windoozzz. So if one has a chance - then ONE SHOULD UPGRADE TO LINUX/UNIX (as there are at least 2 system-wide methodologies on LINUX ("tocken bucket filter", and pspacer/"precise software pacer") to get the stuff working efficiently [i.e. WITHOUT doubling or even trippling the CPU usage in vic just to smooth the burstly traffic]). //------------------------------------------------------------------ => Rant on licencing: Not a legal/pro opinion-based note: before I forget, by chance I've noticed this rather important thing about copyright (which has escaped the attention of hosting site for vic's CVS an ANL?), the file "grabber-bttv.cpp" in ag-media/vic/video directory does NOT appear to have any open source license (it is just copyrighted by some dude with "all rights reserved" statement). So this (from my point of view) should definitely be resolved by the hosting people and we should also decide whether to obtain permission from the dude, or re-write the code ourselves or just drop the code from building and distribution... => Rant on static linking: IF real static linking is requierd, perhaps we should consider the following: http://people.redhat.com/~drepper/no_static_linking.html http://groups.google.com/group/comp.os.linux.development.apps/browse_frm/thread/f664f8f7c19a4a7b => Even if we want our dynamic libs be independent from the same libs residing in the system directories, then that is still possible and should perhaps be considered. Perhaps, the expense of making extra directory or two during an installation process should not be preventing us from moving to dynamic linking as such solves multiple problems (i.e. improves performance and removes the need to distribute plethora of additional files such as linking instructions and a collection of non-LGPL objects). As someone put it: "Select the oldest release you wish to support, and build on that release."