Courtesy of Pablo Nieto, our tech guru, here are the steps we follow to install the ffmpeg in DEBIAN LENNY, so some of the steps may be different, or unnecessary in Ubuntu:
Get the multimedia keyring > wget > http://www.debian-multimedia.org/pool/main/d/debian-multimedia-keyring/debian-multimedia-keyring_2008.10.16_all.de > dpkg -i debian-multimedia-keyring_2008.10.16_all.deb > Include the repos. in sources.list: > nano /etc/apt/sources.list > deb http://www.debian-multimedia.org lenny main > deb-src http://www.debian-multimedia.org lenny main > apt-get update > Install several repository clients > apt-get install checkinstall yasm git-core subversion > apt-get build-dep ffmpeg > Download, configure and build the x264 code from videolan > git clone git://git.videolan.org/x264.git > cd x264 > ./configure > make > checkinstall --pkgname=x264 --pkgversion "1:0.svn`date +%Y%m%d`" > --backup=no --default > Download, configure and build the theora codec > wget http://downloads.xiph.org/releases/theora/libtheora-1.1.1.tar.gz > tar xzvf libtheora-1.1.1.tar.gz > cd libtheora-1.1.1 > ./configure > make > checkinstall --pkgname=libtheora --pkgversion "1.1.1" --backup=no --default > The default libraries are too limited, so we remove them: > apt-get remove libx264-dev > Download, configure and install ffmpeg > svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg > cd ffmpeg/ > ./configure --enable-version3 --enable-libmp3lame --enable-libtheora > --enable-libx264 --enable-libgsm --enable-postproc --enable-libxvid > --enable-libfaac *--enable-pthreads* --enable-libvorbis --enable-gpl > --enable-x11grab *--enable-nonfree* > make > checkinstall --pkgname=ffmpeg --pkgversion "4:0.5+svn`date +%Y%m%d`" > --backup=no --default > I have marked in bold two important options. The first one enables the use of the option "-threads N". The other should be considered if we don't want to use codecs that are patent-encumbered (but there are some other options that enable codecs with patents, so the configure step is *very* important -- and it's well described in the source --). Pablo also says: "The codec must support the use of several threads itself. Sometimes the option -threads 0 doesn't work and it requires a value greater than 0 -it should be ok between 8 and 16-)". I have to give him full credit for this information, because he's being dealing with codecs and encoding issues from much longer than I have. I hope this info is useful. Best regards, Rubén 2011/1/3 Luke Olson <[email protected]> > > Hello Brian, > > > > The 95-110% in top means 95% of one processor to 100% of one processor plus 10% of another. If it said 2400% it would be using all of the 24 cores in the worker. I like htop better than top as it has a usage bar for each core and is easier to use (IMO). Like others have said not all codecs will use all the threads when encoding, but most will if configured properly. Or if left alone you could have 24 concurrent processes going and they would all be just as fast as the one which is good if there are a lot of classes scheduled around the same time. > > > > All the best, > > > > Luke > > > > > > From: [email protected] [mailto: [email protected]] On Behalf Of Brian Bolt > Sent: Thursday, December 30, 2010 10:55 PM > To: Matterhorn Users > Subject: [Matterhorn-users] Ramping up production environment > > > > I have a distributed install running 1.0.1. The Admin and Engage servers each have 16 cores (Intel). The Worker server has 24 cores (AMD). My first one minute capture took about five minutes to process. My second capture is an hour long, and at 1 hour into processing it is currently encoding the presentation (screen) for preview. > > > > I expected that the Worker server would endure the greatest processing load, and 'top' shows that ffmpeg is using 95 - 110% cpu. However, when I run mpstat -P ALL, all processors are greater than 95% idle. Based on what I saw in my VM test environment, I anticipated that a 1 hour capture would take well under 15 minutes to process. > > > > On another note, the amount of space consumed is very large, 345 MB for the one minute capture an 15.6 GB for the one hour capture. Note that I don't yet have the workflow yet configured for streaming, so I anticipate that these numbers would be even larger if streaming were in the mix. > > > > [r...@server matterhorn]# du -h --max-depth=1 > > 25M ./streams > > 8.8G ./files > > 6.5G ./workspace > > 68K ./server1 > > 2.5K ./inbox > > 78K ./searchindex > > 22M ./downloads > > 16G . > > > > Thoughts and ideas are greatly appreciated. > > > > Thanks, > > Brian > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users >
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
