[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> >
 >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)

yes, agreed. But this is not unusual (that the decoder has to handle new situations because of streaming).


Provided the sample descriptions have a 'suitable timestamp for (a) their position in the stream and (b) before the timestamp of the first AU that uses them, I don't see that there is much of a problem.
--
David Singer
Apple Computer/QuickTime


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