Subject: [AVT] MPEG2-TS in RTP - RFC2250 vs ETSI TS 102 034

From: "Greg Herlein" <[email-masked]>
Date: Tue, 10 Oct 2006 11:11:30 -0700

RFC-2250 states:

   Each RTP packet will contain a timestamp derived from the sender's
   90KHz clock reference.  This clock is synchronized to the system
   stream Program Clock Reference (PCR) or System Clock Reference (SCR)
   and represents the target transmission time of the first byte of the
   packet payload.

ETSI TS 102 034 states (section 7.1):

    The 32-bit timestamp in the RTP header is derived from a 90 kHz
clock source that
    may be,  but is not required to be, locked to the clock reference
of one of the programs
    in the transport stream. This clock shall conform to the accuracy
and slew constraints
    for MPEG-2 system clocks as defined in ISO/IEC 13818-1 [62].

It appears to me that implementing RFC-2250 according to a strict
interpretation requires the sender to actually parse the MPEG-TS
stream if the clock is derived from the stream.  The ETSI
interpretation seems to accomplish the same goal with the advantage
that the payload code may treat the single program transport stream as
a relatively opaque payload (split at a usual 7 TS packets per RTP
frame).

I'd like to know what the group thinks about this and if there is
consensus of any kind.  My own next step is to look at the code for
the open source implementations and evaluate exactly how they do it.
I invite commercial vendors to speak out on this regarding their own
implementation.

Thanks.

Greg Herlein

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Sandy (Alexander) MacInnis" <[email-masked]>
Date: Tue, 10 Oct 2006 19:20:46 -0400

Hello,

Please allow me to comment. I generally just "lurk" on this list.
I was responsible for the creation of the MPEG-1 Systems and MPEG-2 
Systems (i.e. Program and Transport stream) standards - this is old stuff now.
I am not as familiar with RTP.

My comment is:

>a relatively opaque payload (split at a usual 7 TS packets per RTP

Creating time stamps from a clock that meets the requirements of the 
MPEG-2 system clock does not accomplish the same goals as creating 
time stamps that are synchronized to the  SCR or PCR.

Whether that matters or not depends on what the application expects.

If the application expects to manage buffers in the way that is 
supported by the MPEG Systems STD (System Target Decoder) model, then 
I believe it needs either the actual MPEG Systems PCR or SCR, or 
fully equivalent values.

If the application does not need this, but rather only needs a 
generally pretty good time base that is not locked to the data, then 
it appears the ETSI spec will do.

I think you are right that generating RTP time stamps that are locked 
to PCR or SCR values requires parsing & examining the TS packet 
headers, and it might also involve some calculation to figure out 
what the RTP time stamps should be if they are not just copied.

***

Having made that comment, I am very interested in what everyone else 
has to say about this.

--Sandy MacInnis

---

From: "Greg Herlein" <[email-masked]>
Date: Tue, 10 Oct 2006 22:48:08 -0700

If the goal is to set the timestamp to be the 'sampling instance of
the first octet in the RTP data packet' then the calculation may be
difficult.  The 7 TS packets in a given RTP packet may not even have
the clock data in them - and if the timestamp is supposed to stay the
same (while the sequence number increments) for packets containing
media, then the streaming code essentially has to decode the stream
enough to be able to get those calculations for each RTP packet.  That
makes scaling the number of streams from one source more limited.

Since the timestamps are not passed to the decoder, I'm wondering of
the only real reason for these timestamps is to calculate network
jitter - there would be no need to do syncronization if the audio and
video are both in the same transport stream (as is normal).  If it's
just jitter, then why even use the same 90kHz clock?

I might be missing something here - I sure hope some of the experts on
the list can chime in and share some wisdom.

Greg Herlein

---

From: Nicholas J Humfrey <[email-masked]>
Date: Mon, 16 Oct 2006 19:21:58 +0100

I have had a similar problem with a tool I have written called  
dvbshout - which takes a DVB Transport Stream and output RTP packets  
(containing MPEG audio/payload type 14).

I wanted the 90kHz clock of the RTP packets to stay in sync with the  
PTS clock of the PES stream (so that if there was an error in the DVB  
stream then the client could recover more easily).

I calculated the RTP timestamp based on the bitrate of the audio and  
then re-synced whenever I got a PES header. However depending on the  
multiplex I was transceiving, I found the the two clocks kept  
drifting in and out of sync...

I found it very hard to calculate the 'correct' timestamp for the RTP  
packets. What is the best practice?

nick.