[Ffmpeg-devel] [PATCH] RTCP valid receiver statistics....

Ryan Martell rdm4
Tue Oct 31 22:17:40 CET 2006

On Oct 31, 2006, at 1:34 PM, Michael Niedermayer wrote:

> Hi
> On Mon, Oct 30, 2006 at 05:43:58PM -0600, Ryan Martell wrote:
>> Here's my patch to get the valid statistics for the RTCP receiver
>> report.  This was basically taken verbatim from RFC 1889.
>> I carefully went over it for trailing whitespace; the only tabs are
>> in the svn diff generated header (before the revision numbers) which
>> I suspect are okay.
>> Note, I also added the url_write() return value check in the #ifdef'd
>> DEBUG case.  This is because (for me) this is returning -2, and my
>> server is timing me out.  This is a different bug, and I was asking
>> on the other thread if this is just my problem or a general issue.
> [...]
>>  /**
>> +* called on parse open packet
>> + */
> the * should be 1 space farthe to the right :)

Actually, I pushed the all to the left.  It was more in line with the  
other ones.

Hope that's okay! ;-)

> [...]
>> +// returns 1 if we should handle this packet.
>> +static int rtp_valid_packet_in_sequence(RTPStatistics *s,  
>> uint16_t seq)
> comment isnt doxygen compatible


> [...]
>> +#if 0
>> +/**
>> +* This function is currently unused; without a valid local ntp  
>> time, I don't see how we could calculate the
>> +* difference between the arrival and sent timestamp.  As a  
>> result, the jitter and transit statistics values
>> +* never change.  I left this in in case someone else can see a  
>> way. (rdm)
> the system time should be used

really?  how do I get system time in 64 bits, without just taking  
time_t and shifting appropriately?  I don't know what the server does  
with the jitter, but i would be afraid of screwing something up if  
the two machine's times aren't close.

> [...]
>>  #endif
>> -        url_write(s->rtp_ctx, buf, len);
>> -        av_free(buf);
>> +        result= url_write(s->rtp_ctx, buf, len);
>> +#if defined(DEBUG)
>> +        printf("result from url_write: %d\n", result);
>> +#endif
>> +       av_free(buf);
> indention is slightly inconsistant


> [...]
>> +#if defined(DEBUG) && 0
>> -#if defined(DEBUG) || 1
> unrelated change?

Nope; I am replacing the old method of checking sequences with the  
new method.

This version of the patch strips it out. (and fixes the above, except  
system time, which I would like to put in a later patch to setup the  
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061031/cad29aa6/attachment.txt>
-------------- next part --------------

(who is slowly ransacking rtp/rtsp.c)

PS: I'm up to my eyeballs in stuff at work; I think it may be  
possible to nuke most of the packet stuff in rtp_h264.c, I just  
haven't had a chance to clean it up yet (since it is currently  
working for me...)

More information about the ffmpeg-devel mailing list