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

[Andrew Ford]

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/7687c84f/attachment.htm>