«

»

Dec 26 2010

What’s been happening with VideoMonkey?

It’s been a long time since anything has been going on with the project, so I thought it was high time to get out some news. Truth is, I’ve been really busy at work and haven’t had time for Video Monkey lately.

But I’ve gotten a new drive to get more encoders into Video Monkey. The code is not in great shape for adding encoders. For one thing commands.xml, the file that contains all the rules and JavaScript code for telling the encoders what to do, is in dismal shape. So I went back to the drawing board.

First, I wanted to get a new version of FFMPeg, the heart of the encoding system. The version in use is ancient and is missing many bug fixed and a few features. You’d think it was easy to get the latest command line utility, but it is far from it. First of all, any version that is available online is either too old, doesn’t have all the needed encoders, or is linked with shared libraries. So I’ve been working at building my own version, which is another mountain to climb.

FFMPeg needs many support libraries some of which are really hard to build. This is the dark side of Open Source Software. You have to depend on the whims of those willing to do the work. For many those whims can be very fickle. Just look at Video Monkey, it has been stale for the last several months because it sole developer (me) was busy with other things. I am happy to be able to use the great work others. These libraries are outstanding and crucial to Video Monkey. I just wish some were easier to build and use.

My initial hope was to make a script that would build all the support libraries and then build ffmpeg. But that is too difficult at this time. So I’ve settled for just getting something to build. And I’ve succeeded at getting version 0.6.1 (the latest at time of this writing), working with the latest support libraries. I hope it works better and is an asset to Video Monkey moving forward.

Next, I wanted commands.xml to be easier to use. I think I’ve got  that, too. I am now using the latest ffpresets files, so H.264 (MP4) output should be better and faster. I’ve also made some improvements to the JavaScript interface. So I hope I am now set to write some new encoders! Look for encoders that output MP4 encoded video. After that I will look at how to encode to FLV, WMV and others. I might even be able to add MKV output (although I dislike the format strongly)!

  • Robert

    You should really try to build from the ffmpeg-git repository. It has a bunch of updates and bufixes including a built-in VP8 decoder. I have been building my own ffmpeg since last March for the old VisualHub application. I found that it is not that difficult to build. I have statically built in the following libraries: xvidcore, x264, vpx8, opencore AMR, GSM, Spex, theora, zlib, and bzip2 into my Leo Intel build.

  • cmarrin

    I’m actually building from the svn repo. Are you saying that ffmpeg-git is a separate repository with later bug fixes than the svn repo?

    OBTW, it seems like some people are having trouble running ffmpeg because it is compiled 64 bit only. I will be doing a quick update soon with a fat binary, containing both a 32 and 64 bit binary. When I do that build I will update to TOT.

    Also, could you send me the ./configure options you build with? I may not be compiling with as many codec options as I should.

  • Robert

    The ffmpeg developers have EOL’d the SVN repo as of r26400. They have converted it to a git repository like the x264 project. Go to http://www.ffmpeg.org/download.html for the info. As for my config, here it is:

    env CPPFLAGS=”-I/usr/local/include” LDFLAGS=”-L/usr/local/ lib” ./configure –prefix=/usr/local –enable-static –disable-shared –enable-pthreads –enable-libmp3lame –enable-libxvid –enable-libx264 –enable-libtheora –enable-libvorbis –enable-libfaac — enable-libopencore-amrwb –enable-libopencore-amrnb –enable-libgsm — enable-libspeex –enable-libnut –disable-ffplay –disable-ffserver — enable-nonfree –enable-gpl –enable-version3 –disable-avfilter — enable-swscale –enable-libvpx

    Some notes:
    – The CPPFLAGS/LDFLAGS are used to force the linker to link my static zlib and bzip2 libraries that I built in /usr/local instead of the system supplied versions.

    – In my build I do not use “–enable-libvpx” because VisualHub does not have the ability to encode files into the VP8/WebM format through the UI. I think you would want to include this for VideoMonkey. Current git version has a built-in VP8 decoder that is faster than the libvpx library.

    – I use”–disable-avfilter” because VisualHub uses ffmpeg options -crop/-pad. These options were replaced with avfilter options in the latest version. My version of ffmpeg restores these options but if libavfilter is not disabled, ffmpeg spits out an error and stops the encoding. You may want to enable it.

  • cmarrin

    Interesting how ffmpeg has shifted to git just like me!

    Thanks for the config. I am missing some of your later flags (libopencore-amrwb, libopencore-amrnb, libgsm, libspeex. libnut and libvpx). I will look into those libraries. It’s getting very painful to get all the prereq’s for ffmpeg. Do you compile all the libs locally or get prebuilt distros?

    I’m not sure I understand your statement about libvpx. Sounds like ffmpeg can decode WebM without it, but not encode?

    I believe the current ffmpeg settings for VM already do the right thing wrt avfilters. I am using the crop filter in one of the formats and it seems to be working correctly.

    Of course “correct” in this context just means that the encoding is successful and produces reasonable video. I can’t say how it will work, if at all, on the target hardware (e.g., Tivo and PSP).

  • Robert

    I compile all of the libraries locally on my machine and then install them into /usr/local/lib. I then remove any *.dylib that are accidentally installed so ffmpeg uses only the static libraries.

    As for libvpx, this library is needed if you want to encode VP8/WEBM from ffmpeg. FFmpeg only includes a native decoder.

    The old -crop filter was removed in SVN 25516 and the old -pad filter was removed in SVN 23050.

    • cmarrin

      Have you successfully compiled a 32 bit binary on Snow Leopard by any chance? I want to put a fat binary of ffmpeg in the next release (which I’m doing quickly to get 32 bit binaries out). But I can’t seem to get a recipe. With info from the web I’ve gotten:

      ./configure –disable-ffplay –disable-ffserver –enable-gpl –enable-pthreads –enable-version3 –enable-avfilter –enable-nonfree –enable-swscale –enable-postproc –enable-filters –enable-runtime-cpudetect –extra-cflags=”-arch i386″ –extra-ldflags=’-arch i386′ –arch=x86_32 –target-os=darwin –enable-cross-compile

      I know that’s doing something different because it gave me errors when I had the –enable-x264 flag set (as well as other). It told me it couldn’t find the library and I believe I only have 64 bit libraries for x264. So I took out all the flags that were looking for extra libs and got configure to successfully run. But making the result still gives me a 64 bit executable.

      Any help would be much appreciated.

  • Robert

    Funny that you should ask. i just upgraded a couple of days ago and got the dreaded “not the correct architecture” in the config.log for ffmpeg. Here’s what I used to build the 32 bit version for me:

    env CPPFLAGS=”-arch i386 -I/usr/local/include” LDFLAGS=”-arch i386 -L/usr/local/lib” ./configure –prefix=/usr/local –enable-static –disable-shared –enable-pthreads –enable-libmp3lame –enable-libxvid –enable-libx264 –enable-libtheora –enable-libvorbis –enable-libfaac –enable-libopencore-amrwb –enable-libopencore-amrnb –enable-libgsm –enable-libspeex –enable-libnut –disable-ffplay –disable-ffserver –enable-nonfree –enable-gpl –enable-version3 –disable-avfilter –enable-swscale

    You will need to build all the libraries in 32 bit mode. I got lucky because I built all mine in leopard before upgrading. So I decided to check this out. I wiped out a couple of my library builds and rebuilt them for Snow Leopard.

    I first put this line into my .profile: export MACOSX_DEPLOYMENT_TARGET=10.4

    x264: I had to modify the x264 configure file by changing “i*86)” to “i*86|x86)” on line 354.
    ./configure –extra-cflags=”-arch i386″ –extra-ldflags=”-arch i386″ –host=x86-apple-darwin8

    lame: worked a bit better
    env CPPFLAGS=”-arch i386″ LDFLAGS=”-arch i386″ ./configure –disable-shared –enable-static

    xvid: worked as well
    env CPPFLAGS=”-arch i386″ LDFLAGS=”-arch i386″ ./configure –disable-shared –enable-static

  • Robert

    CORRECTION FOR XVID:

    env CFLAGS=”-arch i386″ LDFLAGS=”-arch i386″ ./configure –disable-shared –enable-static

    • cmarrin

      That is only if you want a 32 bit executable. Since VM only works on Leopard and above (for API reasons), I want to make all the executables pure 64 bit. It will give a performance boost and make the executable smaller. But right now I’m having trouble cross-compiling ffmpeg and friends using the 10.5 SDK on Snow Leopard. I’m very reluctant to boot into Leopard to do the build, but I might wind up having to do that.

  • cmarrin

    I’ve actually switched everything in VM to 64 bit only. That means it is only for Leopard and above, but that was already a requirement because of some other API I’m using. I want to get this release out soon so I can get verification that it works.