The VideoLAN Forums

Hi everyone,

I've been struggling for several days with a problem. In fact while attemting to read an rtsp live feed from vlc (1.1.11) , via the standalone application or via vlcj in a java swing app, the viewer freezes or is more like in an active loop waiting for data. My guess is those data never come, but instead of stopping the loop (invoking an EOF, a no stream error or a timeout-like argument), vlc keeps waiting, using 100% of one of my computer's cores. When I check the logs, I get the entries below

----------------------------------------------------------------------------------------------------------------------------------------------------------------------
qt4 warning: Input option: rtsp-caching=1200
main debug: adding item ' rtsp://192.168.1.10:1935/LiveRecord/0080F0B8EC36$$'
main debug: rebuilding array of current - root Liste de lecture
main debug: rebuild done - 1 items, index -1
main debug: processing request item rtsp://192.168.1.10:1935/LiveRecord/0080F0B8EC36$$ node null skip 0
main debug: resyncing on rtsp://192.168.1.10:1935/LiveRecord/0080F0B8EC36$$
main debug: rtsp://192.168.1.10:1935/LiveRecord/0080F0B8EC36$$ is at 0
main debug: starting new item
main debug: creating new input thread
main debug: Creating an input for 'rtsp://192.168.1.10:1935/LiveRecord/0080F0B8EC36$$'
qt4 debug: Adding a new MRL to recent ones:
main debug: thread (input) created at priority 1 (../.././src/input/input.c:220)
main debug: thread started
main debug: using timeshift granularity of 50 MiB
main debug: using timeshift path 'C:\Users\Ariel\AppData\Local\Temp'
main debug: `rtsp://192.168.1.10:1935/LiveRecord/0080F0B8EC36$$' gives access `rtsp' demux `' path `192.168.1.10:1935/LiveRecord/0080F0B8EC36$$'
main debug: creating demux: access='rtsp' demux='' path='192.168.1.10:1935/LiveRecord/0080F0B8EC36$$'
main debug: looking for access_demux module: 1 candidate
qt4 debug: IM: Setting an input
live555 debug: RTP subsession 'audio/MPEG4-GENERIC'
main debug: selecting program id=0
live555 debug: RTP subsession 'video/H264'
live555 debug: setup start: 0.000000 stop:0.000000
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

And when I push the stop button, nothing happens. One core is still at 100% busy with vlc which seems to be still waiting for data to come. I get the logs below :

----------------------------------------------------------------------
main debug: incoming request - stopping current input
main debug: dying input
----------------------------------------------------------------------

Anyway i'm out of ideas, and would be happy someone could explain me what's really going on, and how to get vlc out of that state without having to shut it down from the task manager (and thus killing the wrapping app as well in the case of a java swing app).

I tried using several timeout options like rtsp-session-timeout, rtp-timeout, netsync-timeout, mms-timeout, ipv4-timeout, sap-timeout, but none of them seems to be working in this particular case.

Thanks

Ariel.

This is evidently a bug in live555 or in VLC. Playing with options rarely fixes bugs.

Hi,

As I was trying to determine if the bug I'm facing was in live555 or VLC, I started using previous versions of VLC to access the stream. These are the conclusion of my tests :

0.8.6.c : OK

1.1.1 : It works! But at the first launch the player takes some time updating cache for fonts (There is a popup window displaying that message as well as a progress bar).
1.1.2 : Same as 1.1.1
1.1.3 : Same as 1.1.1

1.1.4 : KO
1.1.5 : KO
1.1.6 : KO
1.1.7 : KO
1.1.8 : KO
1.1.9 : KO
1.1.10 : KO
1.1.11 : KO

So while releasing 1.1.4 in order to patch a major vulnerability due to Windows DLL load design, there must have been another modification that caused that bug, or may be it is just handled differently since version 1.1.4 and I evidently don't know how. So if you have any idea how to get it right, I'd be really interested.

Thanks.

Ariel.

can you try 1.2 nightly build ?

Hi,

I just tried with 1.2.0 nightly version, and it still doesn't work. However even though I can't access the stream, vlc is no longer in an active loop consuming every resources the computer has to give.
The are the logs I obtained so far :

-------------------------------------------------------------------------------------------------------------------------------------------------------
qt4 warning: Input option: network-caching=1000
main debug: adding item `rtsp://192.168.1.10:1935/LiveRecord/0080F0B8EC36$$'
qt4 debug: Adding a new MRL to recent ones:
main debug: rebuilding array of current - root Liste de lecture
main debug: rebuild done - 5 items, index 3
main debug: processing request item: rtsp://192.168.1.10:1935/LiveRecord/0080F0B8EC36$$, node: Liste de lecture, skip: 0
main debug: resyncing on rtsp://192.168.1.10:1935/LiveRecord/0080F0B8EC36$$
main debug: rtsp://192.168.1.10:1935/LiveRecord/0080F0B8EC36$$ is at 4
main debug: starting playback of the new playlist item
main debug: creating new input thread
main debug: Creating an input for 'rtsp://192.168.1.10:1935/LiveRecord/0080F0B8EC36$$'
main debug: using timeshift granularity of 50 MiB, in path 'C:\Users\MySelf\AppData\Local\Temp'
main debug: `192.168.1.10:1935/LiveRecord/0080F0B8EC36$$' gives access `rtsp' demux `' path `192.168.1.10:1935/LiveRecord/0080F0B8EC36$$'
main debug: creating demux: access='rtsp' demux='' location='192.168.1.10:1935/LiveRecord/0080F0B8EC36$$' file='\\192.168.1.10:1935\LiveRecord\0080F0B8EC36$$'
main debug: looking for access_demux module: 1 candidate
live555 debug: version 2011.05.25
main debug: no fetch required for (null) (art currently (null))
qt4 debug: IM: Setting an input
live555 debug: connection timeout
live555 error: Failed to connect with rtsp://192.168.1.10:1935/LiveRecord/0080F0B8EC36$$
main debug: no access_demux module matching "rtsp" could be loaded
main debug: TIMER module_need() : 5001.312 ms - Total 5001.312 ms / 1 intvls (Avg 5001.312 ms)
main debug: creating access 'rtsp' location='192.168.1.10:1935/LiveRecord/0080F0B8EC36$$', path='\\192.168.1.10:1935\LiveRecord\0080F0B8EC36$$'
main debug: looking for access module: 1 candidate
main debug: net: connecting to 192.168.1.10 port 1935
main debug: connection succeeded (socket = 1192)
access_realrtsp debug: rtsp connected
access_realrtsp warning: only real/helix rtsp servers supported for now
main debug: no access module matching "rtsp" could be loaded
main debug: TIMER module_need() : 17.205 ms - Total 17.205 ms / 1 intvls (Avg 17.205 ms)
main error: open of `192.168.1.10:1935/LiveRecord/0080F0B8EC36$$' failed
main debug: dead input
main debug: changing item without a request (current 4/5)
main debug: nothing to play
qt4 debug: IM: Deleting the input
main debug: Destroying the input for '192.168.1.10:1935/LiveRecord/0080F0B8EC36$$'
main debug: TIMER input launching for '192.168.1.10:1935/LiveRecord/0080F0B8EC36$$' : 5043.667 ms - Total 5043.667 ms / 1 intvls (Avg 5043.667 ms)
----------------------------------------------------------------------------------------------------------------------------------------

Thanks,

Ariel.

in your last log, it says connection timeout
You could show the live555 logs (run in a linux terminal to see them).
But without a public url to test you are the only one able to debug it.

I guess u're right, but the thing is that I'm dealing with all those troubles at work, and as much as I'd like it, I can't divulge a public url in order to help catching the bug. In the other hand the only OS run on our computers at work is Windows 7 , a company choice, and I had no say in it whatsoever. So I guess I'm kinda stuck here ... :s

I'll try to set up virtual box on my desktop, so that I can install ubuntu and run vlc on it. But concerning version 1.2.0, my guess is that another bug was detected since versions 1.1. to 1.1.3 can read the stream, and version 1.1.4 to 1.1.11 get stuck in a loop trying to access it.

If it broke between VLC 1.1.3 and 1.1.4, it's most likely a regression in liblive55. I have not checked, but I doubt there were any changes in the VLC side of RTSP between those two releases.

on windows you can use msys rxvt console
You can also test live555 directly.

If it broke between VLC 1.1.3 and 1.1.4, it's most likely a regression in liblive55. I have not checked, but I doubt there were any changes in the VLC side of RTSP between those two releases.

Following your intuition, I checked liblive555_plugin.dll, and there was in fact a change between version 1.1.3 and 1.1.4. In order to test it out, I replaced the liblive555 plugin from the vlc 1.1.11 install directory with the one from 1.1.3, and it actually worked. I'm glad, but yet also puzzled.

Nice catch ...

What do I do from here on ?

I don't know, man.

Normally, you'd file a bug to live555... but that project has no bug tracker.

see my previous post : test live555 directly and find the bug in this library