<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear Ross & Remi,<br>
<br>
Thank you for your immediate reply..!<br>
<br>
The bottom line is, that when I am using a crowded network
connection over wifi with<br>
<br>
vlc <a class="moz-txt-link-freetext" href="rtsp://">rtsp://</a><br>
<br>
the video freezes occasionally, but in the end, vlc always resumes
playing. However, with<br>
<br>
vlc filename.sdp<br>
<br>
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<br>
<br>
[0x7fb370c38278] avcodec decoder error: more than 5 seconds of late
video -> dropping frame (computer too slow ?) <br>
<br>
Increasing network buffering does not help.<br>
<br>
Well, I guess it is one of those mysteries (a red herring indeed..!)
that does not have any solution .. <br>
<br>
Regards,<br>
<br>
Sampsa<br>
<br>
[original question]<br>
<br>
<div class="moz-cite-prefix">On 24.07.2015 11:04, Sampsa Riikonen
wrote:<br>
</div>
<blockquote cite="mid:55B1F19E.6090009@iki.fi" type="cite">Dear
List, <br>
<br>
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. <br>
<br>
<br>
a) First some background of my problem. <br>
<br>
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.
<br>
<br>
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 .. <br>
<br>
.. but in a wifi network, multicasting sucks completely (the
cameras/routers are to blame for this). <br>
<br>
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. <br>
<br>
<br>
b) Next, the bug <br>
<br>
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". <br>
<br>
So far so good. Scheme (i) with sdp files works ok and vlc shows
the video allright, when I do "vlc -vvv streamfile.sdp" <br>
<br>
However, when the network becomes crowded (packet drops, bursts,
etc.), the video eventually freezes premanently with: <br>
<br>
[0x7fb370c38278] avcodec decoder error: more than 5 seconds of
late video -> dropping frame (computer too slow ?) (***) <br>
<br>
However, this never happens when I take a direct unicast
connection with vlc, i.e. using "vlc -vvv <a class="moz-txt-link-freetext" href="rtsp://">rtsp://</a>.." !! <br>
<br>
<br>
c) The questions <br>
<br>
1) I imagine that error (***) results from the fact, that rtcp
information is not being read correctly. <br>
- Does this assumption make sense? <br>
- 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.? <br>
- .. 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.) ? <br>
<br>
2) As vlc reads the input "streamfile.sdp", what does it do with
the file .. <br>
- .. passes it "as-is" to live555 ? <br>
- .. parses the file, populates an object with parameters and
then passes that object to live555 ? <br>
- 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..) <br>
- 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 ? <br>
<br>
<br>
Regards, <br>
<br>
Sampsa <br>
<br>
</blockquote>
<br>
[replies]<br>
<br>
Ross:<br>
<br>
<blockquote type="cite">
<div>
<blockquote type="cite" class="">
<div class="">1) I imagine that error (***) results from the
fact, that rtcp information is not being read correctly.<br
class="">
- Does this assumption make sense?<br class="">
</div>
</blockquote>
<div><br class="">
</div>
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.</div>
<div><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class=""> - 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 ?<br class="">
</div>
</blockquote>
<div><br class="">
</div>
The latter.</div>
</blockquote>
<br>
Remi:<br>
<br>
<blockquote type="cite">Le 2015-07-24 11:04, Sampsa Riikonen a
écrit :
<br>
<blockquote type="cite" style="color: #000000;">1) I imagine that
error (***) results from the fact, that rtcp
<br>
information is not being read correctly.
<br>
- Does this assumption make sense?
<br>
</blockquote>
<br>
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.
<br>
<br>
<blockquote type="cite" style="color: #000000;"> - If vlc does
not have access to rtcp/rtp packets, does it default
<br>
back to some other (lame-)scheme of measuring the time, say, the
<br>
arrival time of the packets/frames, etc.?
<br>
</blockquote>
<br>
If RTCP is unavailable, I presume live555 falls back to RTP
timestamps. That is up to live555 though.
<br>
<br>
<blockquote type="cite" style="color: #000000;"> - .. wouldn't it
be cool if vlc would, in such a case, inform about
<br>
this behaviour (i.e. by printing "using xxx scheme for timing",
etc.)?
<br>
</blockquote>
<br>
I don't know how exactly live555 deals with this. But the lack of
RTCP should have no bearing on intra-stream buffering.
<br>
<br>
<blockquote type="cite" style="color: #000000;">2) As vlc reads
the input "streamfile.sdp", what does it do with the file ..
<br>
- .. passes it "as-is" to live555 ?
<br>
</blockquote>
<br>
Reads it into a buffer and passes the buffer to live555.
<br>
<br>
<blockquote type="cite" style="color: #000000;"> - .. parses the
file, populates an object with parameters and then
<br>
passes that object to live555 ?
<br>
</blockquote>
<br>
No.
<br>
<br>
<blockquote type="cite" style="color: #000000;"> - Could you
please point out where in the vlc/live555 source code
<br>
these things are being done? (tried to find them by myself but
no
<br>
success so far..)
<br>
</blockquote>
<br>
modules/demux/live555.cpp
<br>
<br>
<blockquote type="cite" style="color: #000000;"> - Do I need to
specify the rtcp port in the .sdp file, say
<br>
"a=rtcp:50507", or is it calculated automagically as the media
rtp
<br>
port + 1 ?
<br>
</blockquote>
<br>
It should work either way, but this is really up to live555
implementation.
<br>
<br>
<span class="moz-txt-tag">-- <br>
</span>Rémi Denis-Courmont
<br>
<a class="moz-txt-link-freetext" href="http://www.remlab.net/">http://www.remlab.net/</a>
<br>
_______________________________________________
<br>
vlc-devel mailing list
<br>
To unsubscribe or modify your subscription options:
<br>
<a class="moz-txt-link-freetext"
href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a>
</blockquote>
<br>
Ross:<br>
<br>
<blockquote type="cite">
<div>
<blockquote type="cite" class="">
<div class="">
<blockquote type="cite" class=""> - If vlc does not have
access to rtcp/rtp packets, does it default<br class="">
back to some other (lame-)scheme of measuring the time,
say, the<br class="">
arrival time of the packets/frames, etc.?<br class="">
</blockquote>
<br class="">
If RTCP is unavailable, I presume live555 falls back to RTP
timestamps. </div>
</blockquote>
<div><br class="">
</div>
Yes.</div>
<div><br class="">
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<blockquote type="cite" class=""> - .. wouldn't it be cool
if vlc would, in such a case, inform about<br class="">
this behaviour (i.e. by printing "using xxx scheme for
timing", etc.)?<br class="">
</blockquote>
<br class="">
I don't know how exactly live555 deals with this. But the
lack of RTCP should have no bearing on intra-stream
buffering.<br class="">
</div>
</blockquote>
<div><br class="">
</div>
yes, Rémi is correct here.</div>
<div><br class="">
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<blockquote type="cite" class=""> - Do I need to specify the
rtcp port in the .sdp file, say<br class="">
"a=rtcp:50507", or is it calculated automagically as the
media rtp<br class="">
port + 1 ?<br class="">
</blockquote>
<br class="">
It should work either way, but this is really up to live555
implementation.<br class="">
</div>
</blockquote>
<div><br class="">
</div>
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).</div>
<div><br class="">
</div>
<div>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.)</div>
<br class="">
<div apple-content-edited="true" class="">
<span class="Apple-style-span" style="border-collapse: separate;
color: rgb(0, 0, 0); font-family: Helvetica; font-style:
normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-align: -webkit-auto; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing: 0px;
-webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; "><span class="Apple-style-span" style="border-collapse:
separate; color: rgb(0, 0, 0); font-family: Helvetica;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; ">Ross Finlayson<br class="">
Live Networks, Inc.<br class="">
<a href="http://www.live555.com/" class="">http://www.live555.com/</a></span></span>
</div>
<div class=""><br class="webkit-block-placeholder">
</div>
</blockquote>
<br>
<br>
</body>
</html>