search

juancarmena / xuggle

Automatically exported from code.google.com/p/xuggle
0 stars 0 forks source link

If you point Xuggler to a broken .sdp file, it will hang #77

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
From Jez:

Thanks to the debug build (and some nasty gdb debugging... shiver), I
think I've found and solved the problem I was having!

It was actually two problems, I think; one with ffmpeg and one with
Xuggler.

If you feed ffmpeg an invalid SDP file as input, it (well, commandline
ffmpeg.exe) just complains that there are no streams available for
output (cryptic but oh well).  However, whilst 'efiwewebf' obviously
counts as an invalid SDP file, it also seems to barf when you feed it
an SDP file with Mac-style line endings (0D, not 0A).  This, I think,
is an ffmpeg bug in the libavformat/rtsp.c parsing code, somewhere.
How my SDP file came to have those line endings I have no idea;
restored them to Windows (or Unix)-style, and it worked!

The second bug, though, is with (I'm guessing) Xuggler.  Xuggler also
worked after I fixed the SDP file, but it shouldn't have locked up and
maxed out the CPU when the SDP file was invalid.  I'd say it should
have failed on .readNextPacket (ie. returned -1), or if not then,
on .open() although logically maybe you should be able to .open() an
SDP that doesn't contain any stream descriptors, because it might
contain some other data, and you then add the streams dynamically to
the container, which would make .readNextPacket the more logical place
to fail.

I'm afraid I didn't get as far as debugging Xuggler's Java/C++ hybrid
code monster to figure out where the infinite loop was, but you should
be able to reproduce it easily; just feed Xuggler an SDP file (having
done IContainerFormat.setInputFormat("sdp")) that's nonsense, like
'vjoweff'.  Then try and .readNextPacket, and it should lock up.  If
you want some example code of mine, just ask.

PS. I think .readNextPacket may also be broken in another way; the
documentation says it's supposed to return the numebr of bytes read if
successful, but when reading an incoming stream as a result of having
opened an SDP file, it always returns 0, even if some bytes were read
successfully.

Developer Notes:

I'm betting it's because rtsp.c is returning EAGAIN (meaning no data, try
again), and then our read-packet just tries again in an infinite loop. 
I'll check into it while looking at the rtsp.c code.

Original issue reported on code.google.com by art.cla...@gmail.com on 17 Mar 2009 at 12:20

GoogleCodeExporter commented 8 years ago 
Fixed in r248.

Now if we get EAGAIN we will, by default, only retry once (instead of an 
infinite
number of times).  You can change how often we retry with
IContainer#setReadRetryCount(int).

Original comment by art.cla...@gmail.com on 20 Mar 2009 at 9:05