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

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).

Enjoy,

– Art

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.

Changelog:

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 :)

Enjoy,

– Art

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.

http://www.xuggle.com/xuggler/downloads

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

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.

HTTPS & RTMPE Support

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.

Summary

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

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.

Enjoy,

– Art

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://10.10.1.134/appname  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://10.10.1.134/appname 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://10.10.1.134/appname  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

Robert and I have some exciting news we’re announcing today: We’ve been acquired by ConnectSolutions, LLC and have joined their kick-ass team. This is great news for Robert and me, because it helps us get the technology we’ve been working hard on into the hands of paying customers. But it’s also great news for the Xuggler community!

This deal enables us to continue working on Xuggle’s technology, and ConnectSolutions is committed to keeping Xuggler open-source. That means Robert and I can continue our involvement in the video space, but now we have a profitable company behind the project!

I’m sure some of you have some questions, and so here’s a little Q&A section about the deal.

– Art

What just happened?

ConnectSolutions just announced they acquired Xuggle, all of our source code, and our team.  Effective immediately we work for ConnectSolutions. To find out more about ConnectSolutions, visit their website: www.connectsolutions.com.

Is this a good thing for Xuggle?

Hell yes! We get to deploy our technology with real customers in a real business environment, with a team of people we’re excited to work with. What’s not to love?

Is this a good thing for the Xuggler open-source project?

Hell yes! This means Robert and I can afford to still be involved with the project. It means we’ll be integrating Xuggler into products that are used by thousands of live audience members and by real paying customers. And it means any additional updates we release to Xuggler will be tested even more!

Will ConnectSolutions continue to leave Xuggler in the public domain?

Yes. As part of this transaction, ConnectSolutions has committed to leaving Xuggler in the public domain as LGPL-licensed software. In addition, Art and Robert will continue to provide support as we desire to the project.

Will ConnectSolutions provide commercial support for Xuggler?

ConnectSolutions has no current plans to provide commercial support for Xuggler at this time.

But I wanted to license some of Xuggle’s closed-source technology; can I still do that?

Our focus over the next year will be integrating Xuggle’s closed-source technology into ConnectSolutions’ product suite. If you’d like to become a customer of ConnectSolutions, contact us at http://www.connectsolutions.com/contact.html.

We have some exciting news: We’re hiring!  If you meet the following description, I’d love to chat with you:  You are an enthusiastic, self-driven rock star with experience writing high-volume Java-based servers supporting rich Internet applications for real users.  You love to get code into production, but know when to step back and invest in architecture as well.  You like writing code, but also love mentoring your team mates as well.  You love learning new technologies and move from novice to expert quickly.  Terms like Java, Erlang, XMPP, EJabberD, Spring, AMQP, RabbitMQ, FFmpeg, Xuggle, Hudson, JUnit, Virtualization, Flash or MySQL make you curious.

Background on us: We are a small profitable startup with real customers you’ve heard of.  We believe that solving real customer problems is the path to success.  We believe that people want to collaborate, but collaboration means more than text – it means seeing and hearing each other.  We believe that great technology is important, but a great team environment is as important.  We believe that family and work are not mutually exclusive.  We believe that team members should have health-care and should share in the profits we generate today.

If interested, please drop me a note at aclarke@xuggle.com and tell me  a little about yourself.  And for bonus points, tell me how you’ve used Xuggle, Hibernate and/or Spring to build really cool shit before.

Primary Duties and Responsibilities

• You will work with a larger team to architect and develop collaboration applications.
• You will work primarily in Java and SQL, and will work closely with Flex & HTML developers.
• You will provide architecture guidance to multiple development teams
• You will be a significant individual contributor of Java code
• You will review code written by others and serve as a mentor

Required Job Related Skills and Experience

• You have at least five years experience writing server-side code in a production client-server environment (Java preferred).
• You have experience with high-volume production environments.
• You have worked with HTML or Flex teams and provided APIs they use.
• You believe writing unit tests is a critical part of the development cycle.
• You have worked successfully in a fast-paced environment, adapting to changing priorities and features. and making appropriate decisions based on risk.
• You quickly learn new technologies on your own.
• You have strong written and verbal communication skills.
• You have a BS degree in computer science or equivalent experience.
• You are a US Citizen.
• You are based in the Bay Area, California, USA and willing to work in Emeryville.

Additional Qualifications

• Experience with Red5, WowzaMedia, FFmpeg, C++, Erlang, Spring, Hibernate is good.
• Experience with Java application servers such as Tomcat, Jetty, or others.
• Operational experience with both Linux and Windows environments.

You can find the tutorial here.