[vlc-devel] bug in reading rtcp information from .sdp files ?

Sampsa Riikonen sampsa.riikonen at iki.fi
Fri Jul 24 10:04:46 CEST 2015

Dear List,

I think there is a bug in the rtcp syncing when vlc reads ".sdp" 
files.   I'd need some more information from the developers/experts in 
order to confirm this.

a) First some background of my problem.

I'm on a linux box and from there, several threads need to access the 
same video stream coming from an ip cam.. typically, a few threads of my 
own and a vlc client that live visualizes the video.

Now, the best option is to use multicasting (with "--rtsp-mcast" option 
for the vlc client), and that works like a charm in a lan network ..

.. but in a wifi network, multicasting sucks completely (the 
cameras/routers are to blame for this).

The few options that are then left are: (i) to connect to the the ip cam 
with unicast.  Then a daemon thread in the receiving linux box can 
"multiply" the stream by copying the rtp packets (for video, sound, and 
the rtcp/rtp packets) to certain ports (yes, I know this sucks) or (ii) 
turn the unicast into a local multicast inside the linux box.

b) Next, the bug

Whatever option (i) or (ii) I choose, I have to tell the vlc client how 
to access the streams.  The only option for h264 stream is to use the 
.sdp file.  So, I create .sdp files that describe the address, ports and 
file formats.  Let's call it "streamfile.sdp".

So far so good.  Scheme (i) with sdp files works ok and vlc shows the 
video allright, when I do "vlc -vvv streamfile.sdp"

However, when the network becomes crowded (packet drops, bursts, etc.), 
the video eventually freezes premanently with:

[0x7fb370c38278] avcodec decoder error: more than 5 seconds of late 
video -> dropping frame (computer too slow ?)   (***)

However, this never happens when I take a direct unicast connection with 
vlc, i.e. using "vlc -vvv rtsp://.."  !!

c) The questions

1) I imagine that error (***) results from the fact, that rtcp 
information is not being read correctly.
   - Does this assumption make sense?
   - If vlc does not have access to rtcp/rtp packets, does it default 
back to some other (lame-)scheme of measuring the time, say, the arrival 
time of the packets/frames, etc.?
   - .. wouldn't it be cool if vlc would, in such a case, inform about 
this behaviour (i.e. by printing "using xxx scheme for timing", etc.) ?

2) As vlc reads the input "streamfile.sdp", what does it do with the file ..
   - .. passes it "as-is" to live555 ?
   - .. parses the file, populates an object with parameters and then 
passes that object to live555 ?
   - Could you please point out where in the vlc/live555 source code 
these things are being done? (tried to find them by myself but no 
success so far..)
   - Do I need to specify the rtcp port in the .sdp file, say 
"a=rtcp:50507", or is it calculated automagically as the media rtp port 
+ 1 ?



More information about the vlc-devel mailing list