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

From: Stephan Wenger <[email-masked]>
Date: Mon, 11 Mar 2002 14:32:22 +0100

Hi Jan,

At 10:20 AM 3/11/2002 +0100, [email-masked] wrote:
>This is an interesting discussion. I guess that it would help to let RTP 
>time stamp indicate the Decoding Time Stamp, but that such approach causes 
>other problems, is that right ?

The authors of the JVT/H.26L packetization draft thought about
using the decoding timestamp, but we dismissed it in favor of
the sending time.  I don't recall the precise reason, but I believe
we had some uneasiness with the term itself, as it is (so far) not
defined in JVT.

I would be willing to change the draft to "decoding timestamp", and
this will solve the dual-property problem of the RTP timestamp --
assuming that we mean the timestamp for the decoding of one
slice, not picture.  For the frequently discussed reasons we don't know
the decoding timestamp of the whole picture until the final slcie
is sent.

Whether this approach will facilitate media synchronization is another
problem.  I don't believe it does.  But I'm willing to listen.

Regards,
Stephan

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

---

From: Thomas Stockhammer <[email-masked]>
Date: Mon, 11 Mar 2002 14:49:17 +0100

Dear all,

the timestamp seems to be a real animal! Stephan, what do you think :-)?

> problem.  I don't believe it does.  But I'm willing to listen.

I was actually in favor of using the the RTP as DTS when drafting this
proposal.
But we were not sure if this does not cause any other problems. So we went with

the one which seemed to be less ambigious, RFC2250. However, I still support
very much the RTP = DTS concept unless anyone tells me a real problem.

About buffers and timestamp, I have a kind of naive idea.

What is this all necessary for. The encoder has to produce something
the decoder is capable to decode under some buffer constraints.

The DTS is the time the slice (!, not frame) is removed from the receiver
buffer,
decoded and the decoded slice (!) is moved to the reference frame buffer!
The video has to be coded such that the receiver buffer can take the sum of all
bits
assigned to all slices with DTS>current_time.

In addition, we have a time-stamp which allows to remove a frame from the
reference frame buffer. This is neither PTS nor DTS but something inherent
in H.26L. The encoder should also take care that the decoder can take
all slices in the reference frame buffer (pixel based).

The PTS is again different. A third buffer might be a display buffer which
takes all frames which are no more in the reference frame buffer but where
not display yet because of the PTS. Is this necessary?

The profiles give upper limits on receiver buffer and reference frame buffer.

Any problems with this concept?

Best regards

Tom