IHXRTPPacket vs IHXPacket usage

Hello All,

* How is the IHXRTPPacket different from IHXPacket apart from the RTPTime ?

* What is the advantage of using IHXRTPPacket over IHXPacket ? What if I create IHXPacket and set the helix time created from rtp time ?

* In IHXRTPPacket::SetRTP, should the RTPTime be adjusted to the first packet TS offset ? (Meaning should RTP time always start with zero when IHXRTPPacket is used ?)

In XPS fileformat (which is similar to RTSP file format), when RTP packets are received, it sets the same RTP time & Helix time (calculated using TSConverter)in the packet and sends it to depacketizer. Depacketizer is again calculating the Helix time with its own TSConverter. And the time calculated from TSConverter seem to start with some offset instead of zero and audio playback does not happen untill that time. The playback time keeps moving and audio starts playing after the time offset. If the RTP packet ts is adjusted (meaning subtracted to first packet's TS) while setting on IHXRTPPacket, then playout seems to be ok.

Can someone please clarify the above mentioned questions on IHXRTPPacket, so that I can change XPS File format appropriately ?

Thanks,
Rajesh.

---

From: client-dev-bounceshelixcommunity.org [mailto:client-dev-bounceshelixcommunity.org]
Sent: Monday, April 16, 2007 2:08 PM
To: client-devhelixcommunity.org; protocol-devhelixcommunity.org; datatype-devhelixcommunity.org
Subject: [Client-dev] IHXRTPPacket vs IHXPacket usage

Hello All,

* How is the IHXRTPPacket different from IHXPacket apart from the RTPTime ?

* What is the advantage of using IHXRTPPacket over IHXPacket ? What if I create IHXPacket and set the helix time created from rtp time ?

* In IHXRTPPacket::SetRTP, should the RTPTime be adjusted to the first packet TS offset ? (Meaning should RTP time always start with zero when IHXRTPPacket is used ?)

In XPS fileformat (which is similar to RTSP file format), when RTP packets are received, it sets the same RTP time & Helix time (calculated using TSConverter)in the packet and sends it to depacketizer. Depacketizer is again calculating the Helix time with its own TSConverter. And the time calculated from TSConverter seem to start with some offset instead of zero and audio playback does not happen untill that time. The playback time keeps moving and audio starts playing after the time offset. If the RTP packet ts is adjusted (meaning subtracted to first packet's TS) while setting on IHXRTPPacket, then playout seems to be ok.

Can someone please clarify the above mentioned questions on IHXRTPPacket, so that I can change XPS File format appropriately ?

Thanks,
Rajesh.

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
   ;      boundary="----_=_NextPart_001_01C7805A.96BBEF09"


Hello All,

* How is the IHXRTPPacket different from IHXPacket apart from the RTPTime ?

* What is the advantage of using IHXRTPPacket over IHXPacket ?

What if I create IHXPacket and set the helix time created from rtp time ?

* In IHXRTPPacket::SetRTP, should the RTPTime be adjusted to the first packet TS offset ? (Meaning should RTP time always start with zero when IHXRTPPacket is used ?)

In XPS fileformat (which is similar to RTSP file format), when RTP packets are received, it sets the same RTP time & Helix time (calculated using TSConverter)in the packet and sends it to depacketizer. Depacketizer is again calculating the Helix time with its own TSConverter. And the time calculated from TSConverter seem to start with some offset instead of zero and audio playback does not happen untill that time. The playback time keeps moving and audio starts playing after the time offset. If the RTP packet ts is adjusted (meaning subtracted to first packet's TS) while setting on IHXRTPPacket, then playout seems to be ok.

Can someone please clarify the above mentioned questions on IHXRTPPacket, so that I can change XPS File format appropriately ?

Thanks,
Rajesh.
_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/protocol-dev

---

From: ext Milko Boic [mailto:milkoreal.com]
Sent: Wednesday, April 18, 2007 5:13 PM
To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas); client-devhelixcommunity.org; protocol-devhelixcommunity.org; datatype-devhelixcommunity.org
Subject: Re: [Protocol-dev] IHXRTPPacket vs IHXPacket usage

At 12:08 PM 4/16/2007, rajesh.rathinasamynokia.com wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
       ;  boundary="----_=_NextPart_001_01C7805A.96BBEF09"


Hello All,

* How is the IHXRTPPacket different from IHXPacket apart from the RTPTime ?

It is not different beyond that.

* What is the advantage of using IHXRTPPacket over IHXPacket ?

It can differentiate presentation and dispatch time of a packet and retain packet presentation time in sample time base which provides for more accuracy.
Presentation time is given by RTPTime, which is packet's presentation time in units of samples.  Samples relation to seconds is expressed in "SamplesPerSecond" property in the associated stream header.  If the header is absent, the units of RTPTime are to be assumed in milliseconds.

When IHXPacket is used, presentation and dispatch time are assumed to be the same and always expressed in milliseconds.

What if I create IHXPacket and set the helix time created from rtp time ?

No problem as long as helix time is in milliseconds.

* In IHXRTPPacket::SetRTP, should the RTPTime be adjusted to the first packet TS offset ? (Meaning should RTP time always start with zero when IHXRTPPacket is used ?)

No.  However, the following should always be true: ; 0 in RTP time == 0 in helix time.
Given the RTPTime is presentation time, it is directly related to playback time.
Note that in the network RTP stream this is not so.  Network RTP time needs to be normalized to presentation time using NPT, NTP and RTP time-stamps.

In XPS fileformat (which is similar to RTSP file format), when RTP packets are received, it sets the same RTP time & Helix time (calculated using TSConverter)in the packet and sends it to depacketizer. Depacketizer is again calculating the Helix time with its own TSConverter. And the time calculated from TSConverter seem to start with some offset instead of zero and audio playback does not happen untill that time. The playback time keeps moving and audio starts playing after the time offset. If the RTP packet ts is adjusted (meaning subtracted to first packet's TS) while setting on IHXRTPPacket, then playout seems to be ok.

Sound like you have not normalized the RTP time-stamp (converted it to presentation time in NPT coordinate system).

Milko

Can someone please clarify the above mentioned questions on IHXRTPPacket, so that I can change XPS File format appropriately ?

Thanks,
Rajesh.
_______________________________________________
Protocol-dev mailing list
Protocol-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/protocol-dev