NTP Time overflow

Could you provide a bit more context here as to
when and how this overflow happens and what you
mean by 'using the middle 32 bits'.

--greg.


Praveen.Thimmashettynokia.com wrote:
> Hi,
> 
> I am seeing an overflow in NTPTime calculation while
RTCP
> synchronization on live streams (
RTPBaseTransport::handleRTCPSync ).
> This behavior causes 50% of the video frames going
without displayed.
> Hence huge hit on the quality of the streaming.
> 
> We are suppose to use the middle 32 bits out of 64 in
the NTP timestamp
> to calculate NTP Time. This doesn't cause any
overflow.
> 
> I have made the following changes in
> Protocoltransportrtprtptran.cpp.
> 
>  -3276,6 +3277,12 
>                     DPRINTF(D_INFO, ("RTCP:
SenderReport receivedn"));
> 
>                    
m_pReportHandler->OnRTCPReceive(pPkt, ulNow);
> +                   pPkt->ntp_sec = pPkt->ntp_sec
& 0x0000ffff;
> +                   pPkt->ntp_frac =
pPkt->ntp_frac & 0xffff0000;
> +
>  
>
m_pDataTransport->handleRTCPSync(NTPTime(pPkt->ntp_sec
,
>  
> pPkt->ntp_frac),
> 
> Live streams works just fine with these changes. 
> I just want to make sure is there any better way of
handling this.
> 
> Thanks
> Praveen
> 
> 
> 
>
------------------------------------------------------------
------------
> 
> _______________________________________________
> Protocol-dev mailing list
> Protocol-devhelixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev


_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

Hi Greg,
    Live streaming from Vidiator server sends RTCP-Sync
packets. The ntp
sec & ntp frag is on NTPTime obj. The ToMsec function
uses ntp sec and
ntp frag and calculates the msec. The msec calculation unit
result, is
returned and used in rtptran as 32bit integer, resulting in
integer
overflow.
   With the new change, ntp sec's last 16 bit and ntp frag's
first 16
bit will be stored and used for all NTPTime calculations.
Microcore
seems to be doing similar calculation.

Attaching the ethereal capture of the live streaming. Just
to show RTCP
SR are recived during the live streaming.

Thanks,
Praveen. 



 

-----Original Message-----
From: ext Greg Wright [mailto:gwrightreal.com] 
Sent: Monday, October 22, 2007 2:33 PM
To: Thimmashetty Praveen (Nokia-TP-MSW/Dallas)
Cc: protocol-devhelixcommunity.org
Subject: Re: [Protocol-dev] NTP Time overflow

Could you provide a bit more context here as to when and how
this
overflow happens and what you mean by 'using the middle 32
bits'.

--greg.


Praveen.Thimmashettynokia.com wrote:
> Hi,
> 
> I am seeing an overflow in NTPTime calculation while
RTCP 
> synchronization on live streams (
RTPBaseTransport::handleRTCPSync ).
> This behavior causes 50% of the video frames going
without displayed.
> Hence huge hit on the quality of the streaming.
> 
> We are suppose to use the middle 32 bits out of 64 in
the NTP 
> timestamp to calculate NTP Time. This doesn't cause any
overflow.
> 
> I have made the following changes in
> Protocoltransportrtprtptran.cpp.
> 
>  -3276,6 +3277,12 
>                     DPRINTF(D_INFO, ("RTCP:
SenderReport 
> receivedn"));
> 
>                    
m_pReportHandler->OnRTCPReceive(pPkt, ulNow);
> +                   pPkt->ntp_sec = pPkt->ntp_sec
& 0x0000ffff;
> +                   pPkt->ntp_frac =
pPkt->ntp_frac & 0xffff0000;
> +
>  
>
m_pDataTransport->handleRTCPSync(NTPTime(pPkt->ntp_sec
,
>  
> pPkt->ntp_frac),
> 
> Live streams works just fine with these changes. 
> I just want to make sure is there any better way of
handling this.
> 
> Thanks
> Praveen
> 
> 
> 
>
------------------------------------------------------------
----------
> --
> 
> _______________________________________________
> Protocol-dev mailing list
> Protocol-devhelixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev


_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev

This seems right to me. Thanks for catching this.

Eric

=============================================
Eric Hyche (ehychereal.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: client-dev-bounceshelixcommunity.org 
> [mailto:client-dev-bounceshelixcommunity.org] On
Behalf Of 
> Praveen.Thimmashettynokia.com
> Sent: Friday, October 19, 2007 12:51 PM
> To: protocol-devhelixcommunity.org; client-devhelixcommunity.org
> Subject: [Client-dev] NTP Time overflow
> 
> Hi, 
> 
> I am seeing an overflow in NTPTime calculation while
RTCP 
> synchronization on live streams ( 
> RTPBaseTransport::handleRTCPSync ). This behavior
causes 50% 
> of the video frames going without displayed. Hence huge
hit 
> on the quality of the streaming.
> 
> We are suppose to use the middle 32 bits out of 64 in
the NTP 
> timestamp to calculate NTP Time. This doesn't cause any
overflow.
> 
> I have made the following changes in  
> Protocoltransportrtprtptran.cpp. 
> 
>  -3276,6 +3277,12  
>                     DPRINTF(D_INFO, ("RTCP:
SenderReport 
> receivedn")); 
> 
>                    
m_pReportHandler->OnRTCPReceive(pPkt, ulNow); 
> +                   pPkt->ntp_sec = pPkt->ntp_sec
& 0x0000ffff; 
> +                   pPkt->ntp_frac =
pPkt->ntp_frac & 0xffff0000; 
> + 
>                     
>
m_pDataTransport->handleRTCPSync(NTPTime(pPkt->ntp_sec
, 
>                                                        
     
> pPkt->ntp_frac), 
> 
> Live streams works just fine with these changes. 
> I just want to make sure is there any better way of
handling this. 
> 
> Thanks 
> Praveen 
> 
> 


_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/pr
otocol-dev