Xuggle

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

Hi folks,

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.

Hi guys,

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.

The feedback on Xuggler 3.4 has been great, but a lot of people have been asking for RTMP examples.  So I threw together a quick tutorial showing how to use Xuggler 3.4 and RTMP.  The tutorial focuses on using the ‘ffmpeg’ command-line tool to show usage.  You can use the Xuggler API for more flexible programming if you need, but that’s a tutorial for another day.

You can find the tutorial here.

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

Enjoy!

- Art & Robert

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

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:
http://build.xuggle.com/job/xuggler_jdk5_stable/

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 IContainer.seek… 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.

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.

Thanks,

- Art

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.

Enjoy.

- Art

Hi folks,

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

http://octopus.xuggle.com/

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 info@xuggle.com 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.

Thanks,

- Art