[AG-DEV] [Sumover-dev] Re: UCL common lib rtp_recv & frame timing

[Andrew Ford]

Hi,

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.

Does anyone know any good methods/applications for sending smooth RTP
(video) traffic so I can confirm this?

Thanks,
--Andrew

2010/7/30 Andrew Ford <andrew.ford at rit.edu>

> Hi Piers,
>
> 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.
>
> --Andrew
>
> 2010/7/30 Andrew Ford <andrew.ford at rit.edu>
>
> Hi Piers,
>>
>> 2010/7/30 P O'Hanlon <p.ohanlon at gmail.com>
>>
>> Andrew,
>>>
>>> When you mentioned that you'd played with the buffer sizes - I assume
>>> you meant the default send/recv socket buffer size (udpbufsize) in
>>> common/src/net_udp.c:291?
>>>
>>
>> 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.
>>
>>
>>> Also what sort of bit-rate is 'low bit rate' H.264 at 30fps?
>>>
>>
>> 25 kbps - it's just a block moving across the screen so the compression
>> ratio is very good.
>>
>>
>>> One thought is whether you're sending RTCP packets as well and whether
>>> the hiccups correspond to RTCP packet arrival and associated
>>> processing..?
>>> common/src/rtp.c:1894
>>> (not sure why this should be hitting you so hard unless you've got
>>> some weird RTCP packets..?)
>>>
>>
>> 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.
>>
>> --Andrew
>>
>>
>>>
>>> Piers
>>>
>>>
>>>
>>> On 28 July 2010 17:41:41 UTC+2, Andrew Ford <andrew.ford at rit.edu> wrote:
>>> > Hi Rhys,
>>> >
>>> > 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.
>>> >
>>> > --Andrew
>>> >
>>> > 2010/7/27 Rhys Hawkins <rhys.hawkins at anu.edu.au>
>>> >>
>>> >> On Tue, 27 Jul 2010 14:12:37 -0400
>>> >> Andrew Ford <andrew.ford at rit.edu> wrote:
>>> >>
>>> >> >
>>> >> >   timeout.tv_sec = 0;
>>> >> >   timeout.tv_usec = 10000;
>>> >> >   for (int i = 0; i < 1000 && rtp_recv(session, &timeout,
>>> _timestamp); i ++) {
>>> >> >
>>> >> >
>>> >> >     timeout.tv_sec = 0;
>>> >> >     timeout.tv_usec = 10;
>>> >> >
>>> >> >   }
>>> >> >
>>> >>
>>> >> Hi Andrew,
>>> >>
>>> >> All that code is doing is a crude version of:
>>> >>
>>> >>  while (elapsed_time < 10ms) {
>>> >>    process incoming packets
>>> >>  }
>>> >>
>>> >> You could try and replace the for loop with just one call to the
>>> rtp_recv
>>> >> function, ie:
>>> >>
>>> >>  timeout.tv_sec = 0;
>>> >>  timeout.tv_usec = 10000;
>>> >>  rtp_recv(session, &timeout, _timestamp);
>>> >>
>>> >> and see if that fixes your problem.
>>> >>
>>> >> The code above was to handle an issue with DV decoding in that
>>> decoding an
>>> >> entire frame of DV took a certain length of time and during that time
>>> the
>>> >> UDP buffer (kernel side) could overflow causing loss of data. I don't
>>> think
>>> >> it should be the cause of your problems, but things are pretty foggy
>>> that
>>> >> far back in time so it may have other ramifications I've forgotten
>>> about.
>>> >>
>>> >> Cheers,
>>> >>    Rhys
>>> >
>>> >
>>> > _______________________________________________
>>> > Sumover-dev mailing list
>>> > Sumover-dev at cs.ucl.ac.uk
>>> > http://oakham.cs.ucl.ac.uk/mailman/listinfo/sumover-dev
>>> >
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/ag-dev/attachments/20100802/1d705035/attachment.htm>