Subject: Re: [MMUSIC] RTSP: Handling Media Clock Time Jumps in the RTP MediaLayer

From: Magnus Westerlund <[email-masked]>
Date: Tue, 03 Mar 2009 16:58:07 +0100

Hi Ingemar,

The RTSP already includes a mechanism that handles this generic. It is
called RTP-Info headers seq parameter. That provides the client with an
indication of what the first packet is so that it can take the
appropriate action. As what is appropriate is varying with codecs etc I
am hesitant to write up to much about this. Do you have a text proposal?

Cheers

Magnus

Ingemar Johansson S skrev:
> Hi
> 
> In my opinion it would anyway be good to have some text around this with
> a recommendation that the RTP stack (including the jitter buffer) is
> reset when a timestamp glitch occurs.
> We have quite recently had a discussion around crappy RTP stack
> implementations that do RTCP-SR the wrong way, it does not mean that the
> implementers are stupid, just that the specification is vague and leaves
> room for alternative implementation. I can understand that we cannot
> document every odd feature but in this case I believe it does not cost
> much to have some extra text around this issue in the RTSP spec.
> 
> Regards
> Ingemar
> 
>> -----Original Message-----
>> From: Rémi Denis-Courmont [mailto:[email-masked]]
>> Sent: den 19 december 2008 19:12
>> To: [email-masked]
>> Cc: Ingemar Johansson S
>> Subject: Re: [MMUSIC] RTSP: Handling Media Clock Time Jumps
>> in the RTP Media Layer
>>
>> Le jeudi 18 décembre 2008, Ingemar Johansson S a écrit :
>> > The issue that occured to me when I read appendix C.3 is:
>> What happens
>> > if a play request is followed by another play request? It may be
>> > tricky for the decoder alone to know that the playout point
>> changes.
>> > This is I believe not a big issue for stateless audio
>> codecs. However
>> > for predictive codecs that builds upon  the same states in
>> encoder and
>> > decoder this could well cause some very audible (sometimes painful)
>> > artifacts, the only safe way to deal with this is a reset of the
>> > decoder states.
>>
>> The RTP timestamp will jump. The decoder is pretty badly
>> broken if it does not reset (or get resetted by the RTP
>> stack) when this happens.
>>
>> In any case, e.g. the audio buffers will get screwed up by
>> the timestamp gap. Also, you have a somewhat similar problem
>> in case of packet loss.
>>
>> > There are probably some easy fixes to this:
>> > 1) In most (all?) cases there will be a a glitch in the
>> timestamp that
>> > can be used by the decoder to know when to do a reset.
>>
>> Yes.
>>
>> > 2) The sender injects a reset frame (a.k.a codec homing frame) when
>> > the jump is done.
>>
>> This looks like a layer violatio to me. In any case, this is
>> not always do-able. What, for instance, the server could have
>> "precomputed" RTP packets, with transmission timestamps, and
>> know nothing about the internal RTP payloads. Also, this may
>> not be possible with some existing RTP payload formats, if
>> they don't implement such a thing as a reset packet.
>>
>> > 3) Exploit the fact that the receiver will in the PLAY response get
>> > the timestamp corresponding to the jump.
>>
>> In practice, this is the same as 1).
>>
>> > 4) Sender sets the marker bit.
>>
>> Cannot do that. It would not be backward compatible with
>> existing RTP payload format specifications.
>>
>> --
>> Rémi Denis-Courmont
>> http://www.remlab.net/
>>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 6 Mar 2009 10:15:44 +0100

Hi

I agree that there is always a risk that one overspecifies things. I would believe that it is sufficient to state something like.

"A client implementation must ensure that decoder states and jitter buffers are properly initialized when a (new) playout request takes effect".

I don't see a need to secify in more detail than this, I would however welcome if something like this is included in the spec, it may seem like a waste of space but it may remove a few interop issues.

Regards
/Ingemar 

> From: Magnus Westerlund 
> Sent: den 3 mars 2009 16:58
> To: Ingemar Johansson S
> Cc: Rémi Denis-Courmont; [email-masked]
> in the RTP MediaLayer
> The RTSP already includes a mechanism that handles this 
> generic. It is called RTP-Info headers seq parameter. That 
> provides the client with an indication of what the first 
> packet is so that it can take the appropriate action. As what 
> is appropriate is varying with codecs etc I am hesitant to 
> write up to much about this. Do you have a text proposal?
> 
> Cheers
> 
> Magnus
> 
> > In my opinion it would anyway be good to have some text around this 
> > with a recommendation that the RTP stack (including the 
> jitter buffer) 
> > is reset when a timestamp glitch occurs.
> > implementations that do RTCP-SR the wrong way, it does not 
> mean that 
> > the implementers are stupid, just that the specification is 
> vague and 
> > leaves room for alternative implementation. I can 
> understand that we 
> > cannot document every odd feature but in this case I 
> believe it does 
> > not cost much to have some extra text around this issue in 
> the RTSP spec.
> > 
> > Regards
> > Ingemar
> > 
> >> Subject: Re: [MMUSIC] RTSP: Handling Media Clock Time Jumps in the 
> >> RTP Media Layer
> >>
> broken if it 
> >> does not reset (or get resetted by the RTP
> >> In any case, e.g. the audio buffers will get screwed up by the 
> >> timestamp gap. Also, you have a somewhat similar problem 
> in case of 
> >> packet loss.
> >>
> >> This looks like a layer violatio to me. In any case, this is not 
> >> always do-able. What, for instance, the server could have 
> >> "precomputed" RTP packets, with transmission timestamps, and know 
> >> nothing about the internal RTP payloads. Also, this may not be 
> >> possible with some existing RTP payload formats, if they don't 
> >> implement such a thing as a reset packet.
> >>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 06 Mar 2009 11:53:33 +0100

> I don't see a need to secify in more detail than this, I would however welcome if something like this is included in the spec, it may seem like a waste of space but it may remove a few interop issu…

Well, I agree that in most cases this is the correct action. However, in
some of the replacement cases doing a reset will be going to far. I have
rewritten your statement to the following and added it at the end of C.4
"Handling RTP Timestamps after PAUSE".

Note Further: To ensure correct media decoding and usually jitter-buffer
handling reseting some of the state when issuing a PLAY request is needed.

Cheers

Magnus Westerlund