Hi,<br><br>After investigating the sending side again based on a tip from one of the Ultragrid developers, it looks like the problem might actually be on the sending side - when I added some queueing in my gstreamer pipeline for sending, the choppiness was drastically reduced. I'm guessing my reception timing measurement method was being affected by some playout buffering or similar happening inside gstreamer.<br>
<br>Does anyone know any good methods/applications for sending smooth RTP (video) traffic so I can confirm this?<br><br>Thanks,<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>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" target="_blank">andrew.ford@rit.edu</a>></span><div><div></div><div class="h5"><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><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><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><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><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></div></div><br>
</blockquote></div><br>