how to start xuggle

[Yohann Martineau]

hello,

I'm new to xuggle and would like to test it. I've installed xuggle
successfully (ant run-tests and ant install with appropriated
environment variables), but I can't find any xuggle executable anywhere
in the destination directory. I've been looking for a page on the web
site or a file in source tree which would describe the way to start
xuggle, but I found it nowhere.

Tell me if I'm wrong: xuggle is available as a standalone container and
as an application wrapper in red5?

For the moment I would like to test the standalone version, but I don't
know how to launch it...

The answer is probably obvious... but I cannot find it! :-)

Thank you,

yohann

[fahrenheit]

Xuggle is a set of libraries you can use in other programs, a wrapper for
ffmpeg if you like.

I would suggest reading: http://www.xuggle.com/xuggler/tutorials/

That should help figure out some basic usages of xuggle.

[Yohann Martineau]

ok, thank you, sorry, I did not take the time to read all tutorials on
the website, my fault ! (actually, I'm one of those who don't like
videos for developers...) ehm, now I realize that it's simply written in
the README... oops.

Except that it does not integrate in JMF, is it stupid to compare xuggle
to jffmpeg? JNI wrappers for ffmpeg.

Thank you very much,

yohann


fahrenheit a écrit :

[fahrenheit]

I can answer some of that but Art should be able to provide better answers
if needed.

Well, last I checked (a month back or so) almost all FFmpeg java projects
were dead, as in, based on old ffmpeg versions, no updates to current
major versions, etc. And as such you had to forfeit using a up-to-date
ffmpeg releases that solved issues and/or improved compatibility in favor
of older releases.
Xuggle is not meant to be used as JMF plugin, maybe someone can extend
xuggle to do it, but I don't think it's xuggle's purpose to do so.
As for JNI wrappers, well, in my tests xuggle is definitly more stable
than any JNA wrapper I've used, I haven't used any other JNI wrappers, but
I also didn't find anything as up to date as Xuggle, that must be the
reason I can't remember any :P

Hmm.. maybe Art should follow up on this :P

On Sat, 07 Feb 2009 14:49:32 -0000, Yohann Martineau

[Yohann Martineau]

that's right, I've also been looking for clean integration of ffmpeg in
java a few months ago, and I've seen that I was not the first one to
think about JNI wrappers for ffmpeg. But projects were all outdated and
unsupported. Actually, I think almost all java developers are one day
frustrated not to see multimedia integration in standard JRE (I mean
something better than javasound...). I think it's the only domain java
lacks.

To me, JNI is particulary useful when a java developer has to start a
processing which requires high optimization. Then it waits for the
response of this native invocation which generally takes some time. Then
if native implementation has to be "freed" or terminated, it can invoke
a new native method and then do anything else. But when we want to
interact with native implementations frequently and from several
threads, it's generally more complicated. It reminds me a problem I had
in a project using java 1.4, the thread calling native implementations
could not be interrupted. Did you find a workaround for this? maybe this
issue is solved in java 1.5 or java 1.6?

But let's go back to our topic: xuggle. I will read javadoc.

Thank you,

yohann

fahrenheit a écrit :

[Art Clarke]

inline responses

On Sat, Feb 7, 2009 at 7:54 AM, Yohann Martineau
<yohann.m...@gmail.com> wrote:
>
> that's right, I've also been looking for clean integration of ffmpeg in
> java a few months ago, and I've seen that I was not the first one to
> think about JNI wrappers for ffmpeg. But projects were all outdated and
> unsupported.

Yup, that's the need we're trying to fill. In fact, we made a pretty
harsh design decision -- we integrate with the newest FFMPEG on every
FFMPEG checking. See http://build.xuggle.com/ for that in action. In
means we don't fall out of date (but it also means we find problems in
FFMPEG quickly; we've submitted 4 patches to FFMPEG in the last 4
weeks).

> Actually, I think almost all java developers are one day
> frustrated not to see multimedia integration in standard JRE (I mean
> something better than javasound...). I think it's the only domain java
> lacks.

I agree; By the we don't support JMF integration today for two reasons:
1) JMF seems to be dead; Sun hasn't actively developed anything in it in years
2) Neither Robert nor I know much about JMF.

We're open to patches that add support though.

>
> To me, JNI is particulary useful when a java developer has to start a
> processing which requires high optimization. Then it waits for the
> response of this native invocation which generally takes some time. Then
> if native implementation has to be "freed" or terminated, it can invoke
> a new native method and then do anything else. But when we want to
> interact with native implementations frequently and from several
> threads, it's generally more complicated. It reminds me a problem I had
> in a project using java 1.4, the thread calling native implementations
> could not be interrupted. Did you find a workaround for this? maybe this
> issue is solved in java 1.5 or java 1.6?

So we do use JNI, not JNA with Xuggle. Plus we go to some lengths to
enable you to call Xuggle methods without having to worry about
corresponding "free" calls. In general with Xuggle, the garbage
collector will clean up after you (although if methods have open and
close methods, you should use them like you would in JDBC). The
details are complicated, but check out the com.xuggle.ferry package if
you're really interested.

That said, FFMPEG imposes some constraints; you must ensure that calls
on Xuggle objects are synchronized (i.e. don't call
IStreamCoder.decodeVideo() on one thread, and then
IStreamCoder.encodeVideo on another with the same IStreamCoder object
at the same time). Basically, you must treat Xuggler objects like you
would java.util.Map objects -- synchronize access to them. It is safe
to use different objects on different threads though.

Lastly (been discussed before) JNI is slightly faster than JNA but not
by much. The real advantage of JNI is that it can catch a lot of bugs
at compile time and you can optimize slightly more, with the
disadvantage that it requires native code. The real advantage of JNA
is that it doesn't require native code at all, but you can't use it to
catch bugs at compile time. Given the amount of CPU time it takes to
encode and decode video, the performance cost of JNI versus JNA is
essentially the same. We use JNI because we do some pretty
sophisticated C++ to deal with the Ferry stuff above that is easier to
implement in JNI (especially with http://www.swig.org/ which we use as
well).

>
> But let's go back to our topic: xuggle. I will read javadoc.

No problem. We've gotten feedback from some developers that they
would like text-tutorials along with the video tutorials, and we'll
try to do that for new tutorials (and go back and add text to old
ones). That said, volunteers needed :)

Thanks and let us know if you have any problems.

- Art

[Yohann Martineau]

Thank you for this comprehensive response.

inline

On 2/7/09, Art Clarke <acl...@xuggle.com> wrote:
>
> I agree; By the we don't support JMF integration today for two reasons:
> 1) JMF seems to be dead; Sun hasn't actively developed anything in it in
> years
> 2) Neither Robert nor I know much about JMF.
>
> We're open to patches that add support though.

oh, no please don't add jmf support, as you said, it is outdated and
unsupported. I hope nobody is using it seriously.

>
> That said, FFMPEG imposes some constraints; you must ensure that calls
> on Xuggle objects are synchronized (i.e. don't call
> IStreamCoder.decodeVideo() on one thread, and then
> IStreamCoder.encodeVideo on another with the same IStreamCoder object
> at the same time). Basically, you must treat Xuggler objects like you
> would java.util.Map objects -- synchronize access to them. It is safe
> to use different objects on different threads though.

ok, no problem, "manual" synchronization is not a problem.

>
> Lastly (been discussed before) JNI is slightly faster than JNA but not
> by much. The real advantage of JNI is that it can catch a lot of bugs
> at compile time and you can optimize slightly more, with the
> disadvantage that it requires native code. The real advantage of JNA
> is that it doesn't require native code at all, but you can't use it to
> catch bugs at compile time. Given the amount of CPU time it takes to
> encode and decode video, the performance cost of JNI versus JNA is
> essentially the same. We use JNI because we do some pretty
> sophisticated C++ to deal with the Ferry stuff above that is easier to
> implement in JNI (especially with http://www.swig.org/ which we use as
> well).

ok, I'll take a look at it if I find free time...

>
>>
>> But let's go back to our topic: xuggle. I will read javadoc.
>
> No problem. We've gotten feedback from some developers that they
> would like text-tutorials along with the video tutorials, and we'll
> try to do that for new tutorials (and go back and add text to old
> ones). That said, volunteers needed :)

speech recognition would be great here!

thanks again