Xuggle

Hi Folks,

Robert and I are in the process of bundling up a new Xuggler release (3.3) that should be out in the next few weeks.

But for those who like the bleeding edge, you’ll find the following in the tip of tree (and they’ll be in 3.3 AGPL), and feel free to alpha test it:
- We now integrate that latest libx264 (Sep-24), so faster H264 encoding and better rate-control.
- We integrate the latest libtheora release (1.1), which means you can decode theora video even faster (about 15% or so), and get better rate-control when encoding.
- We’ve added the ability to read and write raw audio files — I know weird, but we were so focused on encoded media, that this was something we didn’t get to until now.
- There’ll be a few other bug fixes and minor features.
- And you’ll find a few new demos.

Just wanted you all to know,

- Art

Exciting news folks!  Today BigBlueButton, a cool open-source e-learning suite,  launched Version 0.61 “Titan”.  It comes with lots of new goodies:

• Support for high resolution webcams
• A new and simplified desktop sharing interface
• Much improved slide conversion functionality

You can find the release notes here.

They made another change that we think is awesome; BigBlueButton incorporates Xuggler, and with this release they are abiding by the Xuggler license terms.  That means if you integrate BigBlueButton into your product with their optional desktop sharing component, you must either release your source code under AGPL, or support the BigBlueButton project commercially.

That means everyone wins.

Open-source developers and educational institutions win (as they release their source code back to the community), and people who are not able to release their source code win because they have an affordable commercial option to show their support for the Big Blue Button project.

We’re excited to see our licensing experiment adopted by others in the community as we think it’s an excellent path towards sustainable open-source projects.

Congrats to Fred, Richard, and the team working on BigBlueButton.

- Art

Hi folks,

New feature in tip of tree: You can now use the com.xuggle.xuggler.Converter class to override the input container format type of an input file.  This is particularly useful when dealing with raw media.

Now, to give credit where due; this feature showed up thanks to Aaron Simmons who had the need.  He submitted a great bug report with a patch to Converter that showed what he wanted and exposed a bug in Xugger.  We just fixed the bug, but Aaron’s suggested patch was a good idea, so we implemented a similar version.

Here’s an example of using the new converter flag to change a file of raw audio samples into a WAV file:

java -jar $XUGGLE_HOME/share/java/jars/xuggle-xuggler.jar -icontainerformat s16le -iasamplerate 16000 -iachannels 1 input.raw output.wmv

There a few new methods added to the IContainer class to enable this; see the Converter.java source code for examples of how to use them.

Enjoy, and thanks Aaron!

- Art

Hi folks,

We (Xuggle) are nailing down our development plan for the rest of the year, and wanted to get your input on what’s most important to you. We have a lot of great stuff under development, but want to make sure we’re putting the right priority on the right features. So we’ve put together a very brief (1 page) survey:

http://www.xuggle.com/survey

Please fill it out for us — we’ll use your input to help guide what new features and products we ship over the next year. If you could give us your input by end of next week, that’d be super awesome!

Thanks in advance,

- Art & Robert

Hi folks,

We made a minor change today to Xuggler.  As far as we know, it doesn’t impact any existing users but we wanted to give a shout out to let people know:  We’re no longer supporting using Xuggler via the C++ API, and we no longer allow commercial users to integrate with Xuggler via C++.

Why is this?  Because we’ve found that (a) maintaining C++ backwards compatibility between releases is getting to be very restrictive, (b) 100% of our users and customers to-date (that we know of) have been using only Java to access Xuggler and (c) the current Windows binaries are built with G++ and we’ve had a lot of queries from people wanting to use MSVC++ instead (which we don’t use today).

By dropping official C++ API support the Xuggler project gets the following benefits:

1. We can start to introduce exception throwing into the API now that we’re targeting primarily Java.  C++ exception support across compilers is spotty (e.g. throwing exceptions across DLL boundaries on GCC under windows causes a crash) and was part of the reason we avoided them.
2. We can make intelligent decisions about where to implement functionality; before today we tried really hard to add methods in both the Java API and the C++ API but frankly, some methods make more sense to add in Java code, whereas others make more sense to add in C++.  A good example is the IStreamCoder#getExtraData() method we added today — it makes more sense to implement that method in Java, whereas the lower-level “copy into buffers” methods makes more sense in C++.
3. We can break the binary C++ API and ABI across releases when it makes sense.  Today we can’t change the order we declare methods in a C++ interface for fear that some other (non-Xuggle) person is using the API via C++.  We can’t add data elements to a C++ class that’s part of the ABI.  By removing this support, we can re-order methods, add data, and do whatever we need to more efficiently serve the Java API.  Sine the Java JNI interface dynamically queries shared objects for functions, it doesn’t care about method order.
4. We’re not giving false hopes to Windows developers that they can use Xuggler from C++ in their .NET applications, which helps lower some of our support costs.

Xuggler will continue to be implemented in C++, C, Assembly and Java — we’re just stopping claiming to support a C++ interface that no one is using, and is holding us back.  AGPL users are free to build on the C++ API, but be aware we’re absolutely not going to support it or attempt to maintain compatibility on that interface between releases.  We may at some point in the future introduce a C++ API that is supportable for us (and hopefully works with MSVC++), but that’s in the future.

Let me know if you have any questions, or you were using the C++ API and we weren’t aware.

Thanks,

- Art

On an unrelated note, I’ve put a little project SarynPaint up on google code.  SarynPaint a simple paint program I made a few years back for my friend Saryn.  She was two years old at the time and couldn’t click and drag the mouse, but liked to play on the computer.  It has three mousing modes for progressively older children.  Both a jar file and a disk image containing a Mac application are available.  Have fun!

- Robert

Hi folks,

We just shipped Xuggler 3.2, code named “Dalton”.  Check it out here.

Dalton was all about performance improvement tweaks for us.  Xuggler is now even faster, uses less memory, and is easier to use raw-data with that ever before.  Plus, the very latest FFmpeg, as always, is included, complete with Windows, Mac and Linux installers.

The plan from here is somewhat secret, but you’ll see some big updates from us in the next few months.  Stay tuned.

- Art & Robert

Quick update: Turns out that Apple’s java implementation of webapps can only support Java 1.5, so for now, we’re going to keep supporting 1.5 at least through the 3.x series of Xuggler releases.

Hi folks,

For our next release (3.2) we plan to remove Java 1.5 support.  As far as we know from the people we’ve worked closely with, no one is actually using Java 1.5.  But if you, please let us know by end of this week so we can figure out if we need to revisit this.

Why are we removing Java 1.5 support?

1. Sun is deprecating support for Java 1.5 in 3 months.
2. There are some Java 1.6 optimizations we’d like to take advantage of in Xuggler that we can’t today.

Thanks,

- Art

Hi folks,

It’s been about a month since our 3.1 release and some folks are probably wondering what’s up. Well, we continue to work on Xuggler (the tip of tree includes new features such a 10% performance improvement for multi-threaded servers when allocating memory), but we’ve also been hard at work on another project that we can’t say much about yet.  But stay tuned — Robert and I are pretty excited about it, and we think you will be too.

We continue to be available for questions and support for Xuggler.  Please join the xuggler-users group if you’re running into trouble.  And if you’re a commercial customer, don’t worry, you always take priority!

- Art

A few days earlier than planned, here comes Xuggler 3.1: “Chloe”.

“Chloe” was planned as a bug fix release (and the release we finalize our commercial terms around), but we couldn’t resist and added a few new features as well. Here are some of “Chloe’s” highlights:

• Xuggler Professional licensing terms are now complete and published (the free AGPL-version remains available as always).
• Installers for Linux & Mac users — no more long builds.
• Support for encoding Speex and Vorbis audio and Theora video.
• Support for getting and setting MetaData on files like MP3.
• Support for generating SDP descriptors for RTSP streams.
• Support for creating IVideoPicture and IAudioSamples directly from memory-mapped files.

For details, the release notes are here.

- Art & Robert