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

["Jose Rey" <Jose.Rey at eu.panasonic.com>]

Dave, 

> >
> >While understanding the consequences of this I have found a 
> different 
> >issue.  Before going into it this is my understanding how reception 
> >should
> >work: packets arrive at RTP client, units are extracted from 
> payloads 
> >and assigned timestamp, also sample descriptions.  Then they are 
> >ordered in the buffer according to TS.  The server provides that the 
> >units have the required sample descriptions available at the time of 
> >decoding by assigning same timestamp.  Then we'll end up with a 
> >situation where the same sample description is in the buffer several 
> >times with different timestamp values, is this OK?
> 
> yes, they have the same SIDX and the same content, so they 
> replace each other or not as you like to think;  it's immaterial.
> 
OK.  

> >
> >The question is how the (real-time) decoder 
> >buffers SDs.  I don't know how this actually 
> >happens.  However, regardless of whether we 
> >change the timestamp of the SD to that of the 
> >RTP packet they are in, as proposed in my 
> >previous email or keep it as is, we have to 
> >REQUIRE a minimum buffering time for the SDs at 
> >the DECODER using dynamic SDs.  I.e., it cannot 
> >be that SDs be just discarded once they are used.
> 
> I am not sure what you mean by that.  
> That become 
> active until their index goes out of range...

[In the last sentence, I assume you mean to say "they become...", if so read on]
Exactly, and this keeping track of when an index goes out of range (the dynamic SIDX algo) is done at the decoder that uses the dynamic SDs, not by the RTP payload format, no?  What I intend to say is that with the addition of dynamic SIDXs we are specifying how the *decoder* MUST handle the dynamic SIDX  because the  dynamic SDIX were "invented" in the payload format 

Such observation would go in a section titled something like "Requirements on decoders for supporting dynamic SDs" Does this make sense?
(BTW, I assume static SDs are always stored anyway for the duration of the session, would be good to clarify, though)

> 
> >Because if an SD is present in an aggregate 
> >payload applying to several samples, this 
> >buffering time is determined by the timestamp of 
> >the last text sample in THAT payload that uses 
> >that SD; otherwise if the SD applies only to the 
> >last text sample, and since the SD is given an 
> >earlier timestamp, this is not available anymore 
> >as the last sample is to be displayed. 
> >
> >For specifying the buffering time of dynamic SDs 
> >we have following possibilities:
> >a) new fields that encode it in the TYPE 5 unit 
> >header.  However, we cannot specify a duration 
> >for the SD because the timed text format does 
> >not understand that.
> >b) we REQUIRE the decoder to use the dynamic 
> >SIDX algo to know when a SD should be kept or 
> >deleted.  Is this possible?  (it is not the RTP 
> >client but the decoder that should implement it)
> 
> that's what I expected.  SDs are kept until they 
> are inaccessible or overwritten.
> 
At the decoder, yes.  They are buffered above RTP until they are replaced or become inactive yes, but not at RTP level, since once they are pulled out of the RTP buffer because the timestamp expires they are gone forever.  

> >c) or we could avoid all this by repeating the 
> >SD for every single sample that uses it and so 
> >could SDs be discarded after use. However it 
> >could potentially be too much overhead, but gain 
> >in simplicity.
> 
> ugh
-cut-

Looking forward to your comments,

José


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt