Why Octopus?

Last week we blogged about something called Octopus that we’ve been working on. Octopus is a new server-based technology that takes media from any source (webcams, files, Youtube, etc.), mixes them all together in real time to make one or more new streams.  Which we think is cool.

Today someone asked me why we call it Octopus?  Well, because when we first drew the concept on a whiteboard, it kind of looked like an Octopus:

See what I mean?  Anyway, we’re going to start doing some limited alpha-type testing with Octopus next week.   Stay tuned…

- Art

Octopus is in the house

Phew, it’s been a crazy few months for Robert and me, but we’ve finally gotten a moment to breathe.  While we can’t talk about some of the stuff we’ve done, there is one thing we wanted to show the community because we think you’ll find it as fun as we do

Recently we just finished some major internal milestones on our super-secret “Octopus” project.

What is Octopus?

What does this have to do with Xuggler?

Octopus is the reason we developed Xuggler; Octopus uses Xuggler for decoding and encoding media, but then we add we add all the other magic separately.

When will Octopus go live?

Sometime in 2010.

How can I find out more?

Drop us a line at info@xuggle.com

- Art & Robert

Introducing Xuggler 3.3 – Eliza

Xuggler 3.3 “Eliza” is now live, with the following features:

1. We have returned Xuggler to the LGPL license and are discontinuing the separate commercial license.
2. We have upgraded the x264 (H264) and Theora encoder to the latest versions in our bundled FFmpeg
3. We have upgraded to the latest FFmpeg

You can get Xuggler 3.3 “Eliza” here.

- Art & Robert

The Future of Xuggler…

Starting with Xuggler 3.3, Xuggler will return to the LGPL license and will remain that way from here on out.  You will not need a commercial license to use Xuggler, and you don’t have to release your own code anymore.  The relevant change is already checked in (for those who work off tip of tree) and 3.3 should roll out later this week.

Thanks,

- Art

Awesome Licensing Outcome: Traficon open-sources RTP->RTMP Server

Hi folks,

I just noticed today that a company named Traficon in France has made an attempt to at least partially comply with the Xuggler AGPL license by releasing some of their code(*).  The code converts RTP to RTMP in a Red5 server:

http://sourceforge.net/projects/imux/

Paul Gregoire (of Red5 fame) worked on the project and posted about it to the red5devs list.  But for those who are looking for how to get the RTP->RTMP stuff working, there’s some good starting code there.

- Art

*) Technically the AGPL requires TraffiCon to release all portions of code that are involved in ‘distributing’ this functionality to users, so I would expect more code from them in the future.  But it’s a great start!

Xuggler 3.3

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

BigBlueButton Incorporates Xuggle

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

Xuggler Converter now supports overriding the input container type

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

What features do YOU want?

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

Dropping C++ Support

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