On Hiatus

February 5, 2013

On Hiatus

Hi folks,

For those who do not follow the mailing list, Xuggler development is on hiatus.  Probably permanently.

I have shut down our continuous build server and Community Hero Trevor Burton has kindly agreed to host the documentation and website for the project at www.xuggle.com  But I am not actively developing Xuggler at the moment (haven’t in almost a year).

Thanks to everyone for their support over the years, in particular Robert Harris (my former partner in crime).  Good luck everyone!

– Art

Xuggler 5.4

April 9, 2012

Hot on the heels of Xuggler 5.3, comes Xuggler 5.4.  Another bug-fix release, and only one bug fix at that:

  • “No-install” Jar now works on Ubuntu 11.10 and CentOS 6.2.  If you’re on older version of Ubuntu or CentOS, you’ll need to compile your own version (sorry).

Also, for grins, I’ve written an example for how to use Xuggle within a PlayFramework application.  It’s available from GitHub here.  And to demonstrate the power of no-install, I also deployed it on Heroku earlier today:

Xuggle-Xuggler-Play Demo (Will Be Turned Off By May 2012).


– Art

Xuggler 5.3 has shipped

April 5, 2012

A happy dog, for no good reason

Xuggler 5.3

Xuggler 5.3 was released to our ivy repository last night and is a bug fix release.  Only one new feature — and technically it’s a separate project to aid in testing.  Still, some big bugs with “no-install” for Windows were fixed, and some of the RTSP users out there in the wild will be happier.  Enjoy.

To see how to download it, go to our downloads page.


Next Features

  • New xuggle-xuggler-test project demonstrating maven usage of xuggler and doing VERY intensive tests of Xuggler (takes a long time to run and will eat lots of cpu).

Bug fixes:

  • Windows no-install builds should work correctly
  • RTPS file reading fixed
  • StdioURLProtocolHandler should work on Windows
  • Remove any latest.revision ivy dependencies in xuggler
  • libvpx should link into ffmpeg when cross-compiling on platforms that require PIC
  • pixel formats updated in com.xuggle.xuggler.IPixelFormat for latest ffmpeg version
  • spandsp build no longer uses automake if available on building platform

p.s. I included the happy dog for no reason at all🙂


– Art

Death to installers

April 3, 2012

One of the things that has bugged me about Xuggler from day-zero was the need to separately build and install the native code BEFORE you can do anything useful.  With Xuggler 5.2, for the most common operating systems, this is no longer necessary.  Happy day.


Native code is what gives Xuggler its power, but native code to Java users is strange.  We invested a lot into Xuggler to make it POSSIBLE to build it on many operating systems, but time and time again we’ve found that is still too high of a bar for most users. Who wants to worry about installing C++, C and assembly compilers?  Answer: almost no one (myself included).

What was worse than building though is the need to install Xuggler BEFORE it could run.  This mean setting some obscure operating-system specific environment variables and hoping for the best.  Ugh.

So now, with Xuggler 5.2, the default Xuggler installation INCLUDES all the pre-compiled native code for the 6 most commonly requested operating systems, and can find that code WITHOUT setting environment variables.  That means for Windows users, Xuggler now looks like any other Jar file.  It includes support for both 32 bit AND 64-bit operating systems.  Neat.

There are a few more bug-fixes coming in Xuggler 5.3, but otherwise, we’re narrowing down on the final release of Xuggler for the 5 series.  Enjoy.

– Art


March 16, 2012

Hi there,

First off thank you for everyone who as been very patient with the GIT / new FFMPEG abi-transition as I try to get Xuggle up-to-speed with all the latest changes.  I know it’s been a struggle. and I really appreciate all the feedback.

How Long Before The Tree is Truly Stable?

This transition has taken me a lot more time than expected because I bit off a lot of features, but we’re getting close.  Unfortunately I had hoped to be done by today (March 16, 2012), but unfortunately I’m probably a good two weeks still behind on the plan.  And on top of that, I’m about to take a two week trip (vacation) with my family so I’ll be out of pocket for while.

Which means some of the broken tree elements will remain for at least the rest of March and April, but I give you my commitment it’s the first priority when I get back (at the start of April).

New Features in Xuggler 5

To give people a sense of what all the construction is about, here are the features planned for Xuggler 5 and where they are in terms of completeness.  Hopefully it will whet the appetite for when I return.

Windows 64-bit Builds & Cross-Compiling

Description: Make Xuggler build on Windows 64-bit and cross-compile from linux

Status: 95% complete

Detail: Up until Xuggler 5.0, Xuggler would not build with Windows 64-bit.  And builds on Windows boxes for 32-bit would take about 8 hours (which was a serious disincentive to me maintaining that platform).  That has now been changed (and tested).  It does require you to cross-compile on Linux using mingw-64, but if you do that, you get set of DLLs that (provided they are in your PATH) can be found by Java and used with Xuggler.  To cross-compile Xuggler, install the cross-compiler suite, and then execute:

ant -Dbuild.configure.os=your-cross-compiler-name

For example on my cross-compile box (Ubuntu 11.10) I do:

ant -Dbuild.configure.os=x86_64-w64-mingw32

I call this 95% complete because I’m still tracking down user-reported issues on different platforms, but the major code work is done.

“No-Install” Xuggler

Description: Download xuggle-xuggler.jar and go!

Status: 50% complete for supported operating systems.  POC is done and ‘jar-able’ libxuggle.dll builds on all supported operating systems.  Packaging still requires work.

Detail: This has actually been the single most requested feature in Xuggler’s history and I’m taking a stab at it.  The benefit of it is you will NOT need to ship a separate installer for Xuggler — Xuggler will load native code from the JAR.  For many reasons it’s a non-trivial feature.  Once complete, building from source will be more difficult (slightly) but using Xuggler will not require building by anyone on Windows 32 or 64-bit platforms (Windows Vista and higher), and Mac (x86 and x86_64 platforms only).  I will do a post with full documentation on this, but this one feature is the thing that is causing the most build issues.  Note: xuggler will still be native code — the key difference is that the runtime will try to load the native code from the JAR file and avoid having to set LD_LIBRARY_PATH, PATH or DYLD_LIBRARY_PATH.

A word of warning — once this is done, the xuggle-xuggler.jar will grow from it’s current size (about 1MB) to probably over 100MB.  Don’t worry — there will be options for those who are scared by that🙂

Maven POMs that Work

Description: Xuggler 5 will publish a maven POM that works and is tested.

Status: 0%

Detail: I haven’t started on this yet but it’s how I plan to test that the “no-install” code works.  All of the Exhaustive tests currently in Xuggler will move to a “xuggle-xuggler-test” project in GIT, and that will be built with Maven, not Ant/IVY.  Xuggler itself will continue to be built with ant/ivy (maven cannot easily handle native code, even with some of the great plugins out there).

WebM Support

Description: Incorporate Google’s WebM and VP8 encoder into Xuggler

Status: 90% complete.

Detail: VPX is in the build and builds on our supported platforms.  I still need to add unit tests though to make sure it doesn’t crash at run-time.


Description: Make reading and writing to ‘rtmpe://’ URLs work.

Status: 100% complete (although I cannot auto-test).

Detail:  The major change here (and it was major) was to get openssl to auto-build with Xuggler.

Latest FFmpeg, X264 and libRTMP Releases

Description: Switch Xuggler to use the new FFmpeg APIs and make it easy to integrate FFmpeg changes.

Status: 99% complete.  We have included the latest FFmpeg, X264 and libRTMP releases as of 3/16/2012.

Detail:   Apparently RTPS streaming has some issues but otherwise everything works.

GIT Transition

Description: Migrate from SVN to GIT

Status: 90% complete

Detail: I have transitioned completely to GIT, but the auto-build system (i.e. http://build.xuggle.com/) has not been upgraded.  Personally I have found GIT to be hugely annoying (given how many sub-projects I have to use) and not easy to use.  But it’s the way the world is going, and since most of my upstream projects have moved, we’ve moved too.


So exciting changes are coming, but since most change involves some pain, there’s a little pain along the way.  Again, thanks for everyone’s support, and I’ll be back online at the start of April.

– Art

Ch-ch-ch Changes

February 9, 2012

Hi folks,

If you’ve been following us on our mailing lists, you’ll know I’ve been making some changes over the last few weeks.  To that end, I’m releasing in the wild today the first beta-version of Xuggler 5.0.  What’s different:

  • The very latest FFmpeg (with all the new APIs) has been integrated, allowing you to set options using x264’s new much easier settings
  • I’ve added the vo-aacencAAC audio encoder, which is more stable than FFmpeg’s experimental encoder
  • We’ve moved our main source to GIT
  • There are a few API changes that got deprecated.  The biggest one being that IContainerParameters is now more, and you can now set many options at one time with the IConfigurable.setProperty(IMetaData,IMetaData) api.  To build local java doc when you install, run:
    ant doc-java

The old SVN repository will stay available for a few more weeks, and I’ll eventually move our build server over to it.


– Art

Xuggle now has librtmp support

June 18, 2010

First the bad news; The FFmpeg team has asked me to remove our FAAC-based AAC audio encoder from the binaries we build of Xuggle.  They believe the FAAC encoder is not redistributable as a binary form and, while they don’t actually have anything to do with the FAAC license, have put Xuggle on notice.  So, in an attempt to get off notice, we no longer auto-build FAAC.  Sorry.  That said, if you build Xuggle from source yourself and have already built and installed FAAC on your machine, we’ll link against it if you ask us to.

Now the somewhat inconvenient news; Xuggle now requires libssl, libcrypto and libz to build.  If you’re on ubuntu you probably have those already but to be sure:

apt-get install libssl-dev

This further complicates our windows builds, which remain broken for now.  In fact, we recommend people build from scratch to get the latest version as we’re unlikely to bundle up a formal release soon.

But finally, the GREAT news.  If you install libssl and build Xuggler from source, we now ship Xuggle with the excellent librtmp library.  That’s right… ‘rtmpdump‘ is now bundled with Xuggle, but there’s much more.  The FFmpeg we ship with also uses librtmp for RTMP support.  And the Xuggle Java API uses it too.  In other words, the tip of tree Xuggle now has RTMP, RTMPE, RTMPT, and RTMPS support and much better debugging.  It ships with rtmpdump and other tools.  It allows you to separate application name from path name.  It can intuit your personal desires and make your dreams come true.  It allows you to embed arbitrary AMF in requests (so may work with other CDNs like Akamai and others for their custom security crap).  It supports secure-token.  It supports buffering (like the flash player).  It can make excellent soufflé.  It can “lie” about the webpage you came from.    It is way better than a smart phone*.

Unfortunately it means a slight change in user interface for using FFmpeg with our streams.  Here’s what a new broadcast of a live stream looks like:

ffmpeg -re -i ~/Work/xuggle-xuggler-main/test/fixtures/ucl_h264_aac.mp4 \
 -acodec copy -vcodec copy -f flv "rtmp://  playpath=test live=true"

The quotes for the URL are very important.  You can now pass any parameter RTMPDump supports on the URL provided it is separated via a non-URL-encoded space from the actual URL.

Here’s recording a file from a RTMP server:

ffmpeg -f flv -i "rtmp:// playpath=stream1" \
  -acodec  copy -vcodec copy -y recording.flv

And if you’d like a blow-by-blow formatted packet dump to watch while doing that:

ffmpeg -debug 50 -level 50 -f flv -i "rtmp://  playpath=stream1" \
 -acodec copy -vcodec copy -y recording.flv

Finally, thanks to the kind folks at ConnectSolutions who continue to sponsor this work!

– Art

* way better than an iphone