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

[Andrew Ford]

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/20100730/4ed59667/attachment.htm>