Subject: Re: [AVT] H.26L packetization: the two properties of the RTP timestamp

From: Stephan Wenger <[email-masked]>
Date: Fri, 08 Mar 2002 17:50:38 +0100

At 03:21 PM 3/8/2002 +0100, [email-masked] wrote:
>Stephan,
>
> > As soon as features such as B-frames come into the picture (where
> > the timestamp does not increase monotically with the sequence
> > number), an RTP payload spec designer has two choices: stick
> > to the "sampling instant" concept for the timestamp and de facto
> > require much larger jitter buffers (by allowing higher jitter), or bind
> > the timestamp to something more appropriate than the sampling
> > time.
>
>Do you mean network jitter or are you referring to the difference in time 
>between transport of the data and the presentation of that data. Could you 
>please also elaborate on why the "sampling instant" approach requires much 
>larger jitter buffers than the
>"RFC 2250" approach. I would rather expect the opposite.

Not network jitter, the difference time[..].
When you use an IBBP... coding scheme, the transmission order is
IPBB, but the sampling and presentation order is IBBP.  This is because
you need the reconstructed P frame to reconstruct either of the B frames.
At the receiver, you don't know when a packet was sent, and you also
don't know whether a packet contains something weird like a B picture.
Hence, when using the sampling/presentation time stamp, your jitter
buffer size has to be big (timewise), because it has to "store" at
least the P picture.  Also, your RTCP receiver reports will report a
jitter much higher than the network jitter, namely the number of B
frames multiplied by the picture clock interval (assuming a fixed
picture clock interval, of course).

If you use the transmission time, things are easy.  The order of the
timestamp is monotic as is the order of the sequence number, and the
jitter buffer size is minimal and dependent only on the observed network
jitter.

> > However, that means
> > that we have to rely for exact timing information to the media stream
> > itself ONLY -- though the RTP timestamp can be used to roughly
> > synchronize media streams that do not use Enhanced RPS.  Same is
> > IMHO the case for RFC2250.
>
>Is my assumption correct that at the reciever you would use the RTP time 
>stamp to reconstruct the timing of the H.26L video stream, and that this 
>timing is than used for synchronization (in full analogy with the 
>transport of an MPEG-2 transport stream
>using RFC 2250) ?

I think so.  This is one of the areas where I'm not really sure what to do.
The current H.26L WD contains only the most simple timing information.
It is my believe that, at the end, H.26L will carry some form of exact
relative timing information for some applications and NALs.  For others,
e.g. for low bit rate links, it may be advisable to save the bits and rely
for synchronization only on the arrival time of the data -- the way most
H.320 systems work today (ignoring the video TR, and display pictures
as soon as they are reconstructed).  There will be proposals for this work
item at the next JVT meeting in Fairfax.  My personal opinion would be
to use SEI packets for carrying relative (or even absolute) exact timing
information that is bound to a certain reference buffer -- which can be
the one that contains the currently decoded picture.  The IP/RDP H.26L
NAL could furthermore define a SEI message on its own that establishes
synchronization between the video timing and the transmission time.
But, as I said,  all these are just an ideas for now, not generally accepted
wisdom or WD content.

Stephan

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

---

From: "M. Reha Civanlar" <[email-masked]>
Date: Fri, 8 Mar 2002 13:48:06 -0500

The following is an excerpt from the minutes of the 51st IETF that is
related to this discussion. I just wanted to remind that I am still waiting
for the WG's decision on this issue to make a change in RFC 2250. Taking no
action will be equivalent to deciding that the jitter computation results
reported in RTCP are actually media dependent and media unaware network
elements should be careful about determining network conditions based on
these results (they can still use the jitter computation results for
qualitative comparisons among servers using the same type of media,
however). Any comments?

----------------------------------------------------------------------------
----
"The last functional change requested was related to the RTCP jitter
computation.  An MPEG video frame may need to be carried in more than
one RTP packet.  All such packets carry the same timestamp although
they are sent at different times, and this causes the calculated
jitter to be larger than the true network jitter.  This problem exists
for other payload formats, too, but it is particularly severe when
B-frames are used in MPEG.  The send times of both P- and B-frames are
not related to their timestamps because a future P-frame must be sent
prior to all B-frames that refer to it.  Reha noted that there was a
recent comment on the list stating that the jitter computation based
on the existing definition may actually be useful for the receiver
buffer size determination.  He pointed out that the problem will be
with the media unaware network elements which may try to determine
network state parameters, such as congestion, based on jitter
computations which will not reflect the network jitter in such cases.

Reha suggested that the MPEG payload format should specify a modified
jitter computation that accurately reflects network jitter.  Steve
Casner asked for WG feedback on whether it is reasonable for a payload
format to specify a change in the jitter behavior from what the RTP
spec defines or whether the jitter computation in the RTP spec needs
to be modified in some way.  Steve said a concern is that the
suggested approach requires significant knowledge about the datastream
in order to do the jitter calculation and in many implementations this
may be done in a payload independent portion of the implementation.
Reha stated that the results computed this way will be wrong.
Marshall Eubanks said it doesn't seem to be a good idea to require
people to do something that is wrong.  Steve reiterated his previous
comment about the use of the jitter as a qualitative value to compare
the performance of several servers or a single server over time.  This
is a significant issue that needs to be discussed further on the list."
---------------------------------------------------------------------------
M. Reha Civanlar
[email-masked]

----- Original Message -----
From: "Stephan Wenger" <[email-masked]>
To: <[email-masked]>
Cc: "Stephan Wenger" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; "thomas Stockhammer"
<[email-masked]>
Sent: Friday, March 08, 2002 11:50 AM
Subject: Re: [AVT] H.26L packetization: the two properties of the RTP
timestamp