Introducing Xuggler 3.4

January 31, 2010

OK, a few weeks later than we hoped, but we’ve officially called Xuggler 3.4 done.  See the release notes here.

Big new features:

  • Support for reading and writing RTMP urls (so works with Wowza and FMS).
  • Support for B-frame H264 encoding
  • 10% faster H264 decoding
  • Support for FFmpeg preset files
  • Support for encoding AMR audio (e.g. for inside .3gp mobile media files).
  • We expose a new seek API, along with index files (still experimental).


– Art & Robert

Xuggler 3.4: Yet Another Feature

January 23, 2010

Xuggler 3.4 will contain the ability to decode wide and narrow band AMR audio, and to encode narrow band AMR audio.  That means you’ll be able to create 3GP files for Android and other phones that like to use AMR audio.

As usual, the feature is announced AFTER it’s already in the code base, and the alpha builds can be found here.

– Art

Xuggler 3.4 Alpha Testing

January 17, 2010

Hi folks,

Our build server has (thanks to a mac donation) started automatically building all OSes without (much) manual intervention.  That means our continuous builder will now ship executables for mac, linux and windows:

For those who don’t enjoy building Xuggler themselves, but want to test the very latest versions, that’s where to get them.  And in fact, I’d love for you to start downloading and trying out releases because we’re actively working on the next Xuggler release (3.4) and you can alpha-test it there.

Current features that are committed to 3.4 are:

  • RTMP support (playing and publishing RTMP streams without needing Red5).  Just open “rtmp://…” with IContainer objects and everything happens behind the scenes.
  • H264 B-Frame encoding support; prior versions of Xuggler incorrectly computed timestamps when codecs used B-frames.  We’re fixing that.
  • New Seek API.  See… and the new IIndexEntry object.
  • com.xuggle.xuggler.Configuration.configure(…): the ability to read FFmpeg preset files or other property files to configure Xuggler objects.
All of these methods are implemented in the stable release right now, although we have a known issue with RTMP support and the very latest Red5 tip of tree that I’ll be working on next week.


– Art

New Xuggler Feature Coming Soon: byte, frame #, timestamp range seeking

January 13, 2010

In our continuing push for Xuggler 3.4, there is another change.  Xuggler 3.4 will expose the new (but still experimental) FFmpeg seek API.   The new API (which not all demuxers support) allows seeking within a range of valid values, allows you to specify timestamps, bytes, or frame numbers you want to seek to, allows seeking backwards (for some demuxers), and allows seeking to non-key frames (for some demuxers).

I don’t have a list of exactly what ContainerFormats support efficient seeking, and there is currently no way to query that in FFmpeg.  We won’t be generating our own list, so feel free to share your findings on the xuggler-users list or the Wiki so everyone can learn.

The new method is:

public class IContainer {
public int seekKeyFrame(int streamIndex, long minTimeStamp,
  long targetTimeStamp, long maxTimeStamp, int flags);

This change is in tip of tree right now and can be used if you build from source.  To generate the java documentation for these new methods, build Xuggler tip of tree, and then run:

ant doc-java

Feedback and bug-reports welcome on our support list.  The old seekKeyFrame API will be deprecated at some point in the future in favor of this API so you should migrate your code now.


– Art

New Xuggler Feature Coming Soon: RTMP

January 12, 2010

So we’re working on a big new feature for Xuggler 3.4: RTMP support.

Up until this point if you wanted RTMP you had to integrate Xuggler into a RTMP server such as Red5 and Wowza.  But for 3.4 we’re going to add our own RTMP support, so you can read to and write from RTMP URLs, with no dependency on Red5 or Wowza.  Heck, it means you can even intercept streams coming from an Aodbe Flash Media Server instance (provided it’s security set-up allows you to do that).

No firm ETA on when we’ll call 3.4 done (hopefully this month or next), but if you want to alpha test where we are, go check out tip of tree.  It’s ready for the ‘bleeding edge’ folks among you.

We’ve got RTMP handshaking working with Wowza and Red5, and publishing and playing back FLVs with Sorenson or H264 seems to work.  We’re working through some kinks with publishing M4V format files, but reading them via RTMP should work.  We’ll be doing more work and testing, but I’d like to start getting your feedback.  Once this feature is fully baked, we’ll be officially deprecating our old Xuggle-Xuggler-Red5 adaptor in favor of this approach.  We have no plans to add RTMPE, RTMPT or RTMPF support at this time.

If you don’t know how to build Xuggler from tip-of-tree sources, you can find the instructions here.  Let us know what’s working and not working on the Xuggler-Users list.

One note for those who want to run out right now and use this; your Xuggler programs, if publishing data via RTMP, will need to make sure you don’t overload the RTMP connection.  If you try to cram an entire file down a TCP pipe you’ll get errors.  Instead, send data ‘roughly’ when it would get played by a video player.  For those familiar with the FFmpeg command line program, think of the “-re” option.

Lastly, this support is being implemented in C code, which any changes we make are getting submitted back into FFmpeg and will hopefully show up there too.  Various folks on the FFmpeg team have done the major lifting here — we’re just making it work with Xuggler and helping the FFmpeg team with bug fixes and integration testing.  So if you want to send cookies in support of the feature, they get first dibs on the best ones.


– Art

Octopus Alpha Testing

January 11, 2010

Hi folks,

Last month we mentioned our super-not-so-secret-anymore-project Octopus.  Today we announce the beginning of our alpha-testing program:

We’re going to be running this test instance of our Octopus server over the next few weeks and collecting performance and interaction data.  It’s alpha so please, if you run into issues, let us know by shooting us an e-mail at which as much information as you can give us.

For details on what you’re seeing, check out this explanation page.

We’ll be taking the server up and down over the next few weeks as we add more features and changes.  To help us in the short term, the more you play with it, the more we can improve it.  We’re particularly interested in people using the “join chat” feature with no microphone so we can collect recordings for our echo cancellation features.  As we make improvements, we’ll post details here.

Also, if you’re with a company that is interested in adding this functionality to your product, please contact us as well.  We’d love to hear what you’d like to see in Octopus for your use.


– Art

Why Octopus?

January 6, 2010

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:

Octopus Architecture

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

– Art