Re: [Ccrtp-devel] RTPClockRate, variable bitrate stream

[Federico Montesino Pouzols]

        Hi,

        RTPClockRate is the RTP clock rate :). Seriously though, it is
the rate of the sender reference clock that is used to timestamp
outgoing RTP packets. It is not the same as the MPEG bitstream rate
nor the transmission rate (though sometimes and for most simple codecs
they may have the same value). The RTP clock relates to sampling, not
to transmission. So, for instance, two packets carrying payload for
the same picture may have the same RTP timestamp regardless that they
are transmitted at different times.

        The RTP clock rate for MPEG is usually 90 Khz (see RFC 2250
for MPEG2 and RFC 3016 for MPEG4), which is a common multiple for the
rate of all the components in an MPEG coding system. This means that
you will have to set RTPClockRate to 90000.

        As for what timestamp should be assigned to RTP packets, RFC
3016 says:

"Timestamp: The timestamp indicates the sampling instance of the VOP
   contained in the RTP packet.  A constant offset, which is random, is
   added for security reasons."

        ccRTP will handle the constant offset for you, the rest is
simple (I believe, at least far simpler than with MPEG 2 packetization
rules), you timestamp the packet with the sampling time of the VOP (at
a 90 Khz clock rate), starting from zero at the beginnning of the
session.

        I would say that the RTP clock rate will not change from that
fixed value unless you signal another rate through SDP.

        
        The inter-packet delay is only limited by the machine
performance.  Yes, the number of packets per second that can be
handled depends on its size. I have no concrete estimation, but a
modest machine (PII) can handle several Mbps without any trouble.

On Fri, Dec 05, 2003 at 02:54:23PM +0100, Jean-Paul Wagner wrote:
> Hello all,
> I'm developping a streaming engine which should stream Layered Video (such 
> as MPEG4-FGS bitstreams for example) and adapt the bitrate that is going 
> out whenever feedback is received from the network.
> I planned to use the ccRTP stack to do this, but I don't exactly see how 
> the concept of RTPClockRate works:
> 
> How does RTPClockRate relate to the sending rate and to the timestamps I 
> have to put when I enqueue an outgoing packet?
> Do I have to adjust the clockRate on-the-fly as I adjust the streaming rate?
> Moreover, is there a minimal inter-packet delay between 2 outoing packets 
> that should be observed on this stack? How many packets per second can it 
> handle? I guess it depends on the packet size?
> 
> Thanks for any input,
> --jp.
> 
> 
> 
> 
> _______________________________________________
> Ccrtp-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/ccrtp-devel