Hi Piers,<br><br>Unfortunately it looks like RTCP doesn't have anything to do with it - the problem doesn't coincide with process_rtcp calls at all, plus it's a lot more irregular and happens more often than the RTCP events.<br>
<br>--Andrew<br><br><div class="gmail_quote">2010/7/30 Andrew Ford <span dir="ltr"><<a href="mailto:andrew.ford@rit.edu">andrew.ford@rit.edu</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Piers,<br><br><div class="gmail_quote">2010/7/30 P O'Hanlon <span dir="ltr"><<a href="mailto:p.ohanlon@gmail.com" target="_blank">p.ohanlon@gmail.com</a>></span><div class="im"><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Andrew,<br>
<br>
When you mentioned that you'd played with the buffer sizes - I assume<br>
you meant the default send/recv socket buffer size (udpbufsize) in<br>
common/src/net_udp.c:291?<br></blockquote></div><div><br>At first I was just changing the system buffer sizes, which did affect it in general but didn't help the frame delay (ie, if I set it really low I got tons of packet loss). I also noticed there was a bug in the ANU/VP version of the common library (not in the UCL one) where the buffer size code never got called - I fixed that, tried directly setting the same buffer sizes directly in the code, no difference.<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Also what sort of bit-rate is 'low bit rate' H.264@30fps?<br></blockquote></div><div><br>25 kbps - it's just a block moving across the screen so the compression ratio is very good.<br> </div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
One thought is whether you're sending RTCP packets as well and whether<br>
the hiccups correspond to RTCP packet arrival and associated<br>
processing..?<br>
common/src/rtp.c:1894<br>
(not sure why this should be hitting you so hard unless you've got<br>
some weird RTCP packets..?)<br></blockquote></div><div><br>Thanks, I'll check that out - though I'm not sure if there would be weird RTCP packets since I tried both VLC and gstreamer (same performance) and I doubt they would have the same exact problem.<br>
<font color="#888888">
<br>--Andrew<br> </font></div><div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Piers<br>
<div><div></div><div><br>
<br>
<br>
On 28 July 2010 17:41:41 UTC+2, Andrew Ford <<a href="mailto:andrew.ford@rit.edu" target="_blank">andrew.ford@rit.edu</a>> wrote:<br>
> Hi Rhys,<br>
><br>
> I've tried calling rtp_recv once with both 10ms and 1ms timeout times (as well as no timeout at all) and it looks like it doesn't make a difference. I also tried changing the system UDP buffer sizes to see if that had any effect, but it doesn't seem to.<br>
><br>
> --Andrew<br>
><br>
> 2010/7/27 Rhys Hawkins <<a href="mailto:rhys.hawkins@anu.edu.au" target="_blank">rhys.hawkins@anu.edu.au</a>><br>
>><br>
>> On Tue, 27 Jul 2010 14:12:37 -0400<br>
>> Andrew Ford <<a href="mailto:andrew.ford@rit.edu" target="_blank">andrew.ford@rit.edu</a>> wrote:<br>
>><br>
>> ><br>
>> > timeout.tv_sec = 0;<br>
>> > timeout.tv_usec = 10000;<br>
>> > for (int i = 0; i < 1000 && rtp_recv(session, &timeout, _timestamp); i ++) {<br>
>> ><br>
>> ><br>
>> > timeout.tv_sec = 0;<br>
>> > timeout.tv_usec = 10;<br>
>> ><br>
>> > }<br>
>> ><br>
>><br>
>> Hi Andrew,<br>
>><br>
>> All that code is doing is a crude version of:<br>
>><br>
>> while (elapsed_time < 10ms) {<br>
>> process incoming packets<br>
>> }<br>
>><br>
>> You could try and replace the for loop with just one call to the rtp_recv<br>
>> function, ie:<br>
>><br>
>> timeout.tv_sec = 0;<br>
>> timeout.tv_usec = 10000;<br>
>> rtp_recv(session, &timeout, _timestamp);<br>
>><br>
>> and see if that fixes your problem.<br>
>><br>
>> The code above was to handle an issue with DV decoding in that decoding an<br>
>> entire frame of DV took a certain length of time and during that time the<br>
>> UDP buffer (kernel side) could overflow causing loss of data. I don't think<br>
>> it should be the cause of your problems, but things are pretty foggy that<br>
>> far back in time so it may have other ramifications I've forgotten about.<br>
>><br>
>> Cheers,<br>
>> Rhys<br>
><br>
><br>
</div></div><div><div></div><div>> _______________________________________________<br>
> Sumover-dev mailing list<br>
> <a href="mailto:Sumover-dev@cs.ucl.ac.uk" target="_blank">Sumover-dev@cs.ucl.ac.uk</a><br>
> <a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/sumover-dev" target="_blank">http://oakham.cs.ucl.ac.uk/mailman/listinfo/sumover-dev</a><br>
><br>
><br>
</div></div></blockquote></div></div></div><br>
</blockquote></div><br>