Subject: RE: [AVT] Update (-09) of Timed Tex draft (WAS: RE:Commentsondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)

From: "Jose Rey" <[email-masked]>
Date: Mon, 2 May 2005 10:49:17 +0200

Colin,

[cut agreed]
> 
> > Note that sending a sample description together with every 
> text sample 
> > (or set of samples) may result in a situation where the same sample 
> > description is present in the receiver buffer many times, but with 
> > different timestamp values.  This is a desing choice to 
> ensure correct 
> > reception of sample descriptions and may cause moderate overhead.
> 
> I'm not sure this part's appropriate, since it assumes a 
> particular receiver buffer implementation strategy.
> 

I am assuming that only the basic functionality is implemented: opening RTP packets, reading out units, giving them a TS as the rules describe and storing them in the receiver buffer in TS order.  I intended to be as general as possible.  The last sentence may lead to misunderstanding.  Instead of that one, maybe describing an easy way to avoid this situation is more helpful:  

"Note that sending a sample description together with every text sample (or set of samples) may result in a situation where the same sample description is present in the receiver buffer many times, but with different timestamp values.  This can be avoided by maintaining a list of currently stored sample descriptions (i.e., their SIDX values) and checking this before writing in the buffer."

José

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 2 May 2005 10:06:10 +0100

Jose,

On 2 May 2005, at 09:49, Jose Rey wrote:
...
>>> Note that sending a sample description together with every text 
>>> sample
>>> different timestamp values.  This is a desing choice to ensure 
>>> correct
> I am assuming that only the basic functionality is implemented: 
> opening RTP packets, reading out units, giving them a TS as the rules 
> describe and storing them in the receiver buffer in TS order.  I 
> intended to be as general as possible.  The last sentence may lead to 
> misunderstanding.  Instead of that one, maybe describing an easy way 
> to avoid this situation is more helpful:
>
> "Note that sending a sample description together with every text 
> sample (or set of samples) may result in a situation where the same 
> sample description is present in the receiver buffer many times, but 
> with different timestamp values.  This can be avoided by maintaining a 
> list of currently stored sample descriptions (i.e., their SIDX values) 
> and checking this before writing in the buffer."

This still has the same problem: it talks about implementation 
strategies for the receiver buffer. From the point of the payload 
format, we don't care how many copies of the data are maintained in the 
buffer, or how you remove duplicates.

Colin

---

From: Dave Singer <[email-masked]>
Date: Mon, 2 May 2005 10:32:27 -0700

At 10:49 AM +0200 5/2/05, Jose Rey wrote:
>opening RTP packets, reading out units, giving them a TS as the 
>rules describe and storing them in the receiver buffer in TS order. 
>I intended to be as general as possible.  The last sentence may lead 
>to misunderstanding.  Instead of that one, maybe describing an easy 
>way to avoid this situation is more helpful: 
>
>with different timestamp values.  This can be avoided by maintaining 
>a list of currently stored sample descriptions (i.e., their SIDX 
>values) and checking this before writing in the buffer."
>

I'm with Colin;  leave it out.  It assumes a dumb client, and if 
engineers can't work out how to optimize this, they deserve the 
overhead!
-- 
David Singer
Apple Computer/QuickTime