[vlc-devel] BUG to report: RTSP stream interruption on vlc 0.8.6a results in 100% CPU hang / never quits or recovers

[jsaxe at Crutchfield.com]

Good afternoon. I am completely new to VLC development, and in fact I
don't know if I can fix this bug, but I am affected by it, have a
workaround, and would like to report it. Please tell me how best to
handle this, and I apologize if this isn't the right way to introduce
myself. I haven't even looked at the code or tried to isolate where the
bug is. I already created an account on the Trac server ("JeffSaxe"), if
the answer is I should just create a new ticket.
 
I am making a video recording server for multiple IP video surveillance
cameras from Axis Communications. This is on Linux (CentOS 4.4, if that
matters). Basically I have a short Perl script that wraps a call to the
command-line vlc with no user interface, something like...
 
vlc  -I dummy     rtsp://10.1.5.5/mpeg4/media.amp    --sout
IPVideo/Camera1/Camera1--2007-02-06-114120.mp4   --stop-time=900
vlc:quit         2>&1
 
This starts a stream incoming from the camera (relying on Live555 for
the transport), runs for 900 seconds pouring the stream into .mp4 file,
then quits. The Perl script renames the file and then starts another
one. Works great! (I'll be happy to share the whole setup once it's
done.)
 
Anyway, it worked great under vlc release 0.8.5, but it now has a bug
when I run it with release 0.8.6a, the latest version available when I
recently set up another server. Sometimes the incoming stream will be
interrupted; perhaps the camera was powered off or rebooted, or the
cable was cut, or the Ethernet switch was rebooted -- doesn't matter. If
I watch the output from vlc 0.8.5, then yank the power on the camera,
within just a few seconds it notices the problem and asks Live555 to
issue an RTSP TEARDOWN, then when it contacts the camera again (probably
the TCP socket of the RTSP is rejected with a RST, or something), vlc
correctly closes down, and then my Perl script fires up a new one. But
under vlc 0.8.6a, it never issues the TEARDOWN; it keeps issuing RTSP
keepalives (GET_PARAMETER) every minute, but the output .mp4 file stops
growing in size, and the vlc process starts to consume 100% of one
thread of CPU. I'm running on a 4-processor box, so if I start several
of these in parallel, 4 of them will consume 100% each, or 8 of them
will consume 50% each. But the vlc process is not completely wedged...
it never times out of the 900 seconds, so it never recovers by itself,
but if I manually send it a "kill -QUIT", it politely stops recording
and quits.
 
I'm using exactly the same Live555 library (LIVE555 Streaming Media
v2007.01.17) in each of these two cases, not even recompiled or recopied
to /usr/lib/live, so I assume the Live555 transport library is correctly
catching the stream interruption in either case, but in the older case
that event is being percolated up to its caller (vlc) and handled
properly, while in the newer case that event is being lost somewhere.
Oh, in case it's useful, vlc was configured with:
 
./configure --with-ffmpeg-tree=/home/jeffs/ffmpeg-20051126
--enable-live555 --with-live555-tree=/usr/lib/live --disable-libmpeg2
--disable-wxwidgets --disable-skins2

(or livedotcom in the older 0.8.5 case).
 
Thanks very much for reading, vlc developers. If anyone wants to enlist
me to test a patch, I can; I've checked out of public Subversion
repositories before.
 
-- Jeff Saxe
Network Engineer, IT Systems group
Crutchfield Corporation, Charlottesville, Virginia
434-817-1000 ext. 2111  /  jsaxe at crutchfield.com
<blocked::mailto:jsaxe at crutchfield.com> 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20070206/62dbc482/attachment.html>