Transcoding in Red5 produces errors

[GoogleCodeExporter]

I modified the VideoTranscoderDemoAdapter and VideoTranscoderDemo files
downloaded from somewhere (I can't remember where, but it's definitely
Xuggle source code).  Attached are the two files I use, which essentially
do the following:
1. Create several streams from a single stream, each with a different level
of quality
2. Randomly add text/images to the video for testing.

What steps will reproduce the problem?
1. Install these class files into the videotranscoder project instead of
the existing ones and deploy them to the Red5 demo.
2. Use the Red5 publisher demo to publish a stream to the videotranscoder.
3. Watch the errors in the console.  Threads that experience the exception
shown in the stacktrace stop running, so the video is frozen at the frame
from before the error.  Other streams operate very slowly.

What operating system and JVM version are you using.
- This happens using Vista 64 and Ubuntu 9.04 64 bit using JDK 1.6.0_12. 
I've used the webcam built-in to my ThinkPad W500 as well as a Logitech 2mp
webcam connected via USB.  All combinations produce the same stacktrace,
but there doesn't seem to be a consistent time when it happens vs. doesn't
happen.

Original issue reported on code.google.com by dave.feltenberger on 23 Jun 2009 at 7:51

Attachments:

• stacktrace.txt

[GoogleCodeExporter]

Sorry, forgot to attach the .java files!  Here they are.

Original comment by dave.feltenberger on 23 Jun 2009 at 7:52

Attachments:

• VideoTranscoderDemo.java
• VideoTranscoderDemoAdapter.java

[GoogleCodeExporter]

Hi Dave,

Can you confirm this is with the latest (Xuggler 3.0) code.  If not, please try 
again
with that version.

You can find all the latest at http://www.xuggle.com/xuggler

(This is me being lazy, but I don't have the time right now to deal with old
versions, so your help is appreciated). 

I'll re-open this if/when you confirm it's with the latest.

- Art

Original comment by art.cla...@gmail.com on 23 Jun 2009 at 8:21

• Changed state: Invalid

[GoogleCodeExporter]

This does definitely occur with Xuggler version 3.0.66.

Original comment by dave.feltenberger on 23 Jun 2009 at 8:23

[GoogleCodeExporter]

k; we'll take a look

Original comment by art.cla...@gmail.com on 23 Jun 2009 at 9:05

• Changed state: Accepted

[GoogleCodeExporter]

replace $RED5_HOME/lib/xuggle-xuggler.jar with a know up-to-date version of 
that jar.
 if that fails, attach the resultant $RED5_HOME/log/error.log (or any other logs
files with related errors).

Original comment by tre...@gmail.com on 23 Jun 2009 at 10:41

[GoogleCodeExporter]

The jar was already up to date with version 3.0.66 (I had replaced it before to
ensure it was up to date).  Attached is the log.

Original comment by dave.feltenberger on 23 Jun 2009 at 10:45

Attachments:

• error.log

[GoogleCodeExporter]

Hi Dave,

Just so you know we're not ignoring you, but we can't seem to reproduce your 
problem.
 We're using the very latest (tip of tree) Red5, with the very latest FFmpeg and the
very latest Xuggler.

Have you tried using the tip of tree Xuggler?

- Art

Original comment by art.cla...@gmail.com on 24 Jun 2009 at 4:02

[GoogleCodeExporter]

I'm using tip-of-the-tree Red5 (0.8.1, right?), but 3.0.66 Xuggler from the 
download
page.  I can try the tip of the tree Xuggler to see if that helps.  I'll update 
after
I've done that.

Original comment by dave.feltenberger on 24 Jun 2009 at 4:21

[GoogleCodeExporter]

Tip of tree should be 0.9 in Red5, and should be 3.1.712 (or later) in Xuggler.

The xuggle-xuggler-red5 adapter hasn't changed since 3.0 (but will in the next 
few
days for an unrelated reason).

- Art

Original comment by art.cla...@gmail.com on 24 Jun 2009 at 4:23

[GoogleCodeExporter]

Okay, I've pulled down the heat from both Red5 and Xuggle Google Code projects, 
built
them, and deployed.  The error is still there, unfortunately.  Attached is the 
new
error log, which has a little more information than the previous build.

Interestingly, the unchanged stream that's directly published does not have this
issue (i.e. if you publish a stream named "blah", and then play the stream named
"blah" instead of one of the xuggle_-prepended ones, it works fine).

Original comment by dave.feltenberger on 24 Jun 2009 at 8:39

Attachments:

• red5-xuggler-error.txt

[GoogleCodeExporter]

(Pulled down the *head* from Red5/Xuggle, that should say...)

Original comment by dave.feltenberger on 24 Jun 2009 at 8:40

[GoogleCodeExporter]

Actually I prefer pulled down the heat.

Dave, we're going to have to sit on this until next week, but we'll take a look 
then.

- Art

Original comment by art.cla...@gmail.com on 25 Jun 2009 at 4:53

[GoogleCodeExporter]

Hi Dave,

Try getting the latest Xuggler (the version 3.1 candidate you upgraded to had an
error in) and the latest Xuggler-Red5-Adapater (from ivy) (3.0.757).  I added a
workaround to the Red5 adapter that lets it continue even if Red5 sends a 
corrupt
packet (which appears to be what happened with your version).

Let me know if that fixes the issue and I'll mark this closed.

- Art

Original comment by art.cla...@gmail.com on 2 Jul 2009 at 6:19

[GoogleCodeExporter]

As a link back, the relevant checkin is r757

Original comment by art.cla...@gmail.com on 2 Jul 2009 at 6:39

[GoogleCodeExporter]

Hi Art --

I pulled down the latest this morning around 11 (Eastern) from the trunk of 
both Red5
and Xuggler (including xuggler-red5) and built them from source.  Looks like the
issue is still there -- it just stops transcoding after it experiences the error
mentioned above.  One interesting thing to note, however, is that it only 
happens
when there are multiple threads going at it.

I've checked my code and I can't see any obvious threading issues, but I don't 
know
exactly how the event and threading model works in Red5 so perhaps, for 
instance,
it's not safe to share one IBroadcastStream object between the transcoders?

Dave

Original comment by dave.feltenberger on 3 Jul 2009 at 6:15

[GoogleCodeExporter]

It is absolutely not safe to share one transcoder between the broadcast 
streams. 
They need to be one-to-one.

- Art

Original comment by art.cla...@gmail.com on 3 Jul 2009 at 6:18

[GoogleCodeExporter]

You said one transcoder between broadcast streams is not safe.  I assume it's 
also
not safe to have one broadcast stream for many encoders as well?  (Your second
sentence seems to cover that, but I want to make sure).

And assuming it must be 1-to-1, how do I take one broadcast stream and create
multiple output streams?  Is that even possible with Red5/Xuggler?

Original comment by dave.feltenberger on 3 Jul 2009 at 6:23

[GoogleCodeExporter]

The com.xuggle.red5.Transcoder class listens to ONE BroadcastStream and 
transcodes to
ONE BroadcastStream.  That's all it does.

The Red5IO handler (com.xuggle.red5.io) translates from Red5 into a format that
Xuggler can read, and the Transcoder relies on that.

Is it possible to take one broadcast stream and create multiple output streams 
with
multiple encoders, absolutely.  But you'll need to write code to do it.  The
Transcoder really is to solve a specific problem -- you want to translate one 
stream
into another.  It can be useful to see what's it doing to solve your specific
problem, but you'll have to write the code that sets up the multiple encoders.

Also, bear in mind that using the transcoder to transcode one broadcast stream 
into a
new broadcast stream with Red5, you can have as many clients watch the new 
broadcast
stream as you like (so re-encode once, share with many) in Red5 by having them 
all
connect to the new stream name.

Hope that helps.  Can you confirm that the one-to-one mapping works for you so 
I can
close this bug?

Thanks,

- Art

Original comment by art.cla...@gmail.com on 3 Jul 2009 at 6:57

[GoogleCodeExporter]

Thanks Art.  Yes, the one-to-one mapping works for me.  I'll dig in to see what 
I can
do with one-to-many.

Original comment by dave.feltenberger on 3 Jul 2009 at 7:00

[GoogleCodeExporter]

You should also be able to run multiple Transcoders on multiple Broadcast 
streams in
one process (limited by available CPU and memory).

Original comment by art.cla...@gmail.com on 3 Jul 2009 at 7:03

• Changed state: Invalid

[GoogleCodeExporter]

Hi dave,
   I am also trying to make multiple streams with one broadcast stream. Have you done
it ?   or i just stick to it that I have to write the code for transcoder ?

Regards,
Tamour

Original comment by tamourah...@gmail.com on 21 Dec 2009 at 9:19