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

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 18 Dec 2008 12:57:38 +0100

Hi

I don't know if this is a real issue but I suspect it may be if predictive speech codecs like AMR or G.729 are used. Question is also if it should be mentioned in the the RTSP spec or if it is a just a corner case.

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.  

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. 
2) The sender injects a reset frame (a.k.a codec homing frame) when the jump is done. 
3) Exploit the fact that the receiver will in the PLAY response get the timestamp corresponding to the jump. 
4) Sender sets the marker bit. 

I believe that video does not have this issue as one then have to anyway adjust the new play point to a valid value that gives a decent video playback.

Comments welcome

Regards
/Ingemar
******************************************* 
Ingemar Johansson 
Senior Research Engineer, IETF "nethead" 
EAB/TVP - Multimedia Technologies 
Ericsson Research Ericsson AB 
Box 920 S-971 28 Luleå, Sweden 
Tel: +46 (0)10 7143042 
ECN: 852-43042 
ECC: 852-19042
Mobile: +46 (0)730 783289 
Visit http://labs.ericsson.com !
******************************************* 
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Sun, 21 Dec 2008 20:51:20 +0100

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.
> 
> > 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.
> 
> 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.
> 
> In practice, this is the same as 1).
> 
> Cannot do that. It would not be backward compatible with 
> existing RTP payload format specifications.
> 
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
>