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

Piers O'Hanlon p.ohanlon at cs.ucl.ac.uk
Tue Aug 3 04:41:37 CDT 2010


Howabout the old rtptools - you may need to tweak it.

Otherwise you could sue some other app to stream - VLC or Darwin
streaming server..?

Piers

On 2 August 2010 18:47, Andrew Ford <andrew.ford at rit.edu> wrote:
> 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
>>>> >
>>>> >
>>>
>>
>
>


More information about the ag-dev mailing list