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

[Sampsa Riikonen]

Dear Ross & Remi,

Thank you for your immediate reply..!

The bottom line is, that when I am using a crowded network connection 
over wifi with

vlc rtsp://

the video freezes occasionally, but in the end, vlc always resumes 
playing.  However, with

vlc filename.sdp

Under exactly the same conditions, the video freezes and never recovers 
again (it shows the same image untill hell freezes over), with the error 
message

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

Increasing network buffering does not help.

Well, I guess it is one of those mysteries (a red herring indeed..!) 
that does not have any solution ..

Regards,

Sampsa

[original question]

On 24.07.2015 11:04, Sampsa Riikonen wrote:
> 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 ?
>
>
> Regards,
>
> Sampsa
>

[replies]

Ross:

>> 1) I imagine that error (***) results from the fact, that rtcp 
>> information is not being read correctly.
>>  - Does this assumption make sense?
>
> No.  VLC (specifically, the LIVE555 library that VLC uses when reading 
> a SDP file (or acting as a RTSP client)) receives RTCP packets, and 
> automatically generates properly-synchronized presentation times based 
> on incoming RTCP “SR” packets.  These (properly-synchronized) 
> presentation times are passed to VLC’s “live555.cpp” interface module, 
> and thus to VLC proper.
>
>>  - 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 ?
>
> The latter.

Remi:

> Le 2015-07-24 11:04, Sampsa Riikonen a écrit :
>> 1) I imagine that error (***) results from the fact, that rtcp
>> information is not being read correctly.
>>   - Does this assumption make sense?
>
> That would seem rather unlikely. Also RTCP does not have much 
> practical effects when receiving a single RTP stream. It is mostly 
> useful for cross-stream synchronization.
>
>>   - 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.?
>
> If RTCP is unavailable, I presume live555 falls back to RTP 
> timestamps. That is up to live555 though.
>
>>   - .. 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.)?
>
> I don't know how exactly live555 deals with this. But the lack of RTCP 
> should have no bearing on intra-stream buffering.
>
>> 2) As vlc reads the input "streamfile.sdp", what does it do with the 
>> file ..
>>   - .. passes it "as-is" to live555 ?
>
> Reads it into a buffer and passes the buffer to live555.
>
>>   - .. parses the file, populates an object with parameters and then
>> passes that object to live555 ?
>
> No.
>
>>   - 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..)
>
> modules/demux/live555.cpp
>
>>   - 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 ?
>
> It should work either way, but this is really up to live555 
> implementation.
>
> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel 

Ross:

>>>  - 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.?
>>
>> If RTCP is unavailable, I presume live555 falls back to RTP timestamps.
>
> Yes.
>
>
>>>  - .. 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.)?
>>
>> I don't know how exactly live555 deals with this. But the lack of 
>> RTCP should have no bearing on intra-stream buffering.
>
> yes, Rémi is correct here.
>
>
>>>  - 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 ?
>>
>> It should work either way, but this is really up to live555 
>> implementation.
>
> Right now the LIVE555 library doesn’t recognize the “a=rtcp:” SDP 
> attribute; instead it (if “a=rtcp-mux” is not present) assumes that 
> RTP will use the even port, and RTCP will use the odd port (i.e., even 
> port+1).
>
> But anyway, as Rémi noted, if you have only a single stream (e.g., 
> video only), then RTCP is pretty much irrelevant to VLC, so focusing 
> on it is a ‘red herring’.  Your problem is simply that you have a 
> crappy network.  (You may, however, be able to compensate somewhat for 
> this by increasing VLC’s buffering; there’s a configuration option 
> somewhere for this.)
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20150724/cee43777/attachment.html>