RE: [Nokia-private-dev] RTP timestamp issue when streamming from vidiator server(Live streaming)

Saleem,

The time-stamps computed below are correct.  That part of the code is 
functioning correctly.  Time-stamps in Helix client are intended to 
wrap-around and it is perfectly valid to start a live stream at 0xFFFFFFFF 
time stamps just as it is at 0.  Apparently there is a glitch someplace 
downstream that does not handle the time-stamp wrap-around properly.  Thus, 
the buffering behavior you see.  You could check the inflow the packets 
into the renderer and OnTimeSync signal into the renderer and based on this 
decide if the problem is up or down stream from the renderer.

To specifically answer your question, from the two options you presented, 
dropping the packets prior to the indicated offset is the better 
option.  The logic would need to apply only for live streams and would need 
to throw away packets until the first packet >= indicated offset is 
found.  The test would need to run only during start-up phase not to 
confuse later wrapped time-stamps with the pre-start time stamps.  This 
solution is not ideal - but may practically do the job.  Adjusting the 
offset could result in loss of A/V sync.

This code should be placed within  if (m_bWaitForStartInfo) block:

HX_RESULT
RTPBaseTransport::_handlePacket(IHXBuffer* pBuffer, HXBOOL bIsRealTime)
{
...
     if (m_bWaitForStartInfo)
     {
         if (m_StartInfoWaitQueue.GetCount() == 0)
         {

You would also want to make sure to compare in wrap-around safe manner.
E.g.:
if (((LONG32) (ts - offset)) < 0)
{
         // throw away
}

Ideal solution is to find the down stream time-stamp wrap-around problem 
and correct.

Thanks,
Milko

At 02:59 PM 5/20/2008, [email protected] wrote:

>As per the tester the media player starts to stream from the server link 
>then at 0:01 "Buffering", then again at 0:03 "Buffering" and gets stuck in 
>Buffering.
>Here is an extract from the helix trace log received from the 
>tester(Attached helix trace log). Please look at the first packet log, the 
>RTP packet time is 164000. HXTimeval and RTPTimeval calculated using this 
>value is a huge value 4294951296(ie, 164000(RTP Packet time) 
>-180000(RTPOffset time) =
>  negative value => converted to unsiged => 4294951296). I think it is a 
> possible cause to get the above error. Please look at the attached helix 
> log for more detail.
>
>[13:13:07.610] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:RTSP¿2491753876¿0336¿RTPBaseTransport[0x71d140]::_handlePacket() 
>PKT(Strm=1): (Seq=     1,RTPTime=    164000) -> (HXTimeval=4294
>[13:13:07.610] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:966296,RTPTimeval=4294951296)|
>[13:13:09.469] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:RTSP¿2491755808¿0336¿RTPBaseTransport[0x71d140]::_handlePacket() 
>PKT(Strm=1): (Seq=     2,RTPTime=    166560) -> (HXTimeval=4294
>[13:13:09.532] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:966456,RTPTimeval=4294953856)|
>[13:13:09.532] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:RTSP¿2491755860¿0336¿RTPBaseTransport[0x71d140]::_handlePacket() 
>PKT(Strm=1): (Seq=     3,RTPTime=    169120) -> (HXTimeval=4294
>[13:13:09.532] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:966616,RTPTimeval=4294956416)|
>[13:13:10.735] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:RTSP¿2491756929¿0336¿RTPBaseTransport[0x71d140]::_handlePacket() 
>PKT(Strm=1): (Seq=     4,RTPTime=    171680) -> (HXTimeval=4294
>[13:13:10.735] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:966776,RTPTimeval=4294958976)|
>[13:13:10.735] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:RTSP¿2491756931¿0336¿RTPBaseTransport[0x71d140]::_handlePacket() 
>PKT(Strm=1): (Seq=     5,RTPTime=    174240) -> (HXTimeval=4294
>[13:13:10.735] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:966936,RTPTimeval=4294961536)|
>[13:13:11.125] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:RTSP¿2491757461¿0336¿RTPBaseTransport[0x71d140]::_handlePacket() 
>PKT(Strm=1): (Seq=     6,RTPTime=    176800) -> (HXTimeval=4294
>[13:13:11.125] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:967096,RTPTimeval=4294964096)|
>[13:13:11.125] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:RTSP¿2491757463¿0336¿RTPBaseTransport[0x71d140]::_handlePacket() 
>PKT(Strm=1): (Seq=     7,RTPTime=    179360) -> (HXTimeval=4294
>[13:13:11.125] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:967256,RTPTimeval=4294966656)|
>[13:13:11.125] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:RTSP¿2491757464¿0336¿RTPBaseTransport[0x71d140]::_handlePacket() 
>PKT(Strm=1): (Seq=     8,RTPTime=    181920) -> (HXTimeval=
>[13:13:11.125] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:   120,RTPTimeval=      1920)|
>[13:13:11.141] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:RTSP¿2491757468¿0336¿RTPBaseTransport[0x71d140]::_handlePacket() 
>PKT(Strm=1): (Seq=     9,RTPTime=    184480) -> (HXTimeval=
>[13:13:11.141] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:   280,RTPTimeval=      4480)|
>[13:13:11.141] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:RTSP¿2491757469¿0336¿RTPBaseTransport[0x71d140]::_handlePacket() 
>PKT(Strm=1): (Seq=    10,RTPTime=    187040) -> (HXTimeval=
>[13:13:11.141] xti1:MCU_ASCII_PRINTF; channel:0xE0; 
>msg:   440,RTPTimeval=      7040)|
>
>
>----------
>From: ext Milko Boic [mailto:[email protected]]
>Sent: Tuesday, May 20, 2008 3:56 PM
>To: Adookkattil Saleem (Nokia-D-MSW/Dallas); 
>[email protected]; [email protected]; 
>[email protected]
>Subject: Re: [Nokia-private-dev] RTP timestamp issue when streamming from 
>vidiator server(Live streaming)
>
>At 01:22 PM 5/20/2008, [email protected] wrote:
>>Content-class: urn:content-classes:message
>>Content-Type: multipart/alternative;
>>         boundary="----_=_NextPart_001_01C8BAB7.3D5EE1DA"
>>
>>Hi,
>>
>>There is a live vidiator server streaming link and upon trying to stream 
>>from this link helix client receives few audio stream RTP packets with 
>>timestamp less than the RTPOffset time initially. It causes helix time 
>>calculation failure.
>
>What is the failure?
>
>
>>Here is the RTP PLAY command and PLAY response from vidiator server.
>>
>>PLAY dynstream RTSP/1.0
>>CSeq: 7
>>User-Agent: RealMedia Player HelixDNAClient/10.0.0.6839 (S60 HX 
>>cvs_cays221_20080327:05:00:00utc 27 Mar 2008 21:00)
>>Session: C03A5301C621C22D
>>Range: npt=0-
>>Bandwidth: 1432572
>>
>>RTSP/1.0 200 OK
>>CSeq: 7
>>Date: Tue, 15 Apr 2008 16:34:11 GMT
>>Session: C03A5301C621C22D
>>Range: npt=now-
>>RTP-Info: url=rtsp://10.63.48.228/dynstream/2;seq=1;rtptime=180000, 
>>url=rtsp://10.63.48.228/dynstream/1;seq=1;rtptime=180000
>>
>>Server: Vidiator Server/3.3
>>
>>Sample RTP Audio Packet timestamp sequence
>>
>>SEQ: 1,  Timestamp: 164000*
>>SEQ: 2,  Timestamp: 166560*
>>SEQ: 3,  Timestamp: 169120*
>>SEQ: 4,  Timestamp: 171680*
>>SEQ: 5,  Timestamp: 174240*
>>SEQ: 6,  Timestamp: 176800*
>>SEQ: 7,  Timestamp: 179360*
>>SEQ: 8,  Timestamp: 181920
>>SEQ: 9,  Timestamp: 184480
>>SEQ: 10, Timestamp: 187040
>>SEQ: 11, Timestamp: 189600
>>SEQ: 12, Timestamp: 192160
>>
>>Sample RTP Video Packet timestamp sequence
>>SEQ: 1,  Timestamp: 180000
>>SEQ: 2,  Timestamp: 187200
>>SEQ: 3,  Timestamp: 194400
>>SEQ: 4,  Timestamp: 201600
>>SEQ: 5,  Timestamp: 208800
>>SEQ: 6,  Timestamp: 216000
>>SEQ: 7,  Timestamp: 223200
>>SEQ: 8,  Timestamp: 226800
>>SEQ: 9,  Timestamp: 234000
>>SEQ: 10, Timestamp: 241200
>>SEQ: 11, Timestamp: 244800
>>SEQ: 12, Timestamp: 252000
>>
>>We could fix this error in couple of ways as given below.
>>
>>1) Drop RTP packet(s) with timestamp < RTP offset time
>>2) If the first RTP packet timestamp is less than the received RTP offset 
>>time  correct RTP offset time to first RTP packet time.
>>
>>Looking for input/suggestion from community to make a fix to this failure.
>>
>>Thanks
>>Saleem
>>_______________________________________________
>>Nokia-private-dev mailing list
>>[email protected]
>>http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
>

_______________________________________________
Helix-client-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev