Subject: [MMUSIC] RTSP 2.0: Seek-style RAP and conditional execution

From: Magnus Westerlund <[email-masked]>
Date: Sun, 01 Nov 2009 12:43:26 +0100

Hi,
(as document author)

During the WG last call I received this comment from two different
individuals.

Logged tracker issue:
https://sourceforge.net/tracker/?func=detail&aid=2890240&group_id=23194&atid=377744

> When using seek-style RAP and repositioning in a playing media: If the RAPs
> are far enough from each other a repositioning request may actually result
> in a media point that is further back the current play position. Thus,
> desired if the repositioning only happened under the condition that the
> client will receive media closer to the desired point.
> 
> Example:
> -- Playback time is at t=15 seconds.
> -- User drags marker forward to seek to t=20 seconds
> -- Client issues the seek (PLAY with appropriate Range)
> -- Server responds starting with a RAP at t=13 seconds;
> our seek forward has made us go backwards!
> 
> The commenters notice it that it would be desirable that the seek only
> happen if playing point gets closer to the desired target.
> 
> Proposals to solve this could be a new seek-style that is conditional.
> Another one is too make the normal on conditional. The question is how to
> indicate why things has happened in a certain way, and how to handle the
> response so this is clear. 

After some thought I think it makes sense to create two different
seek-styles for RAP, one that is conditional and that is not. The reason
is that some clients may aggressively flush its buffer or have a
situation where it needs to really go to a RAP despite that the playing
point was closer to the requested position than the RAP.

Thus if create a new RAP policy, which here will call RAPcond. Then it
would work such that the server when receiving a request will compare
the RAP closet prior to the desired point expressed in the Range header
with the current play-point. If the RAP is closer, than it will 200 ok
and deliver that. However, if the current playing point is closer then
the server could respond with a error message. Thus indicating that it
will continue with the previous request. The error class here isn't
obvious, but I guess a 4xx as we have other pre-conditioned errors here.
Maybe 466 "Media precondition not meet". I don't think 412 fits the bill
as it talks about the resource not being the correct one.

Feedback appreciated.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
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: "SEVERA Mike" <[email-masked]>
Date: Tue, 3 Nov 2009 13:41:02 -0600

Hi. 

I think it would be helpful to clarify the contexts in which RAPcond would be valid. For example, I don't think the described behavior makes sense if the seek point is backwards. (Something more like a time-window might be useful there, but that would be quite a different implementation.)
 
This style is also meaningless in the context of a replacment PLAY (eg end-time only), and possibly when resuming from PAUSE (especially for live or any other context where "now-" range might be used.)

Although I think it could safely be ignored in the end-of-PLAY then new PLAY case, those scenarios probably should be thought through.

And the distinction between client playback time and server current play time should be made explicit. I don't think it changes the scenarios at all, but in some cases it could mean you have more information at the client to use in deciding which seek style to use (eg a RAP exists in the jitter buffer, etc), and if so, that information could be provided in the doc's description.

Thanks,

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Sunday, November 01, 2009 3:43 AM
To: mmusic (E-mail)
Subject: [MMUSIC] RTSP 2.0: Seek-style RAP and conditional execution

Hi,
(as document author)

During the WG last call I received this comment from two different individuals.

Logged tracker issue:

> When using seek-style RAP and repositioning in a playing media: If the 
> RAPs are far enough from each other a repositioning request may 
> actually result in a media point that is further back the current play 
> position. Thus, desired if the repositioning only happened under the 
> condition that the client will receive media closer to the desired point.
> 
> Example:
> -- Server responds starting with a RAP at t=13 seconds; our seek 
> forward has made us go backwards!
> 
> Another one is too make the normal on conditional. The question is how 
> to indicate why things has happened in a certain way, and how to 
> handle the response so this is clear.

After some thought I think it makes sense to create two different seek-styles for RAP, one that is conditional and that is not. The reason is that some clients may aggressively flush its buffer or have a situation where it needs to really go to a RAP despite that the playing point was closer to the requested position than the RAP.

Thus if create a new RAP policy, which here will call RAPcond. Then it would work such that the server when receiving a request will compare the RAP closet prior to the desired point expressed in the Range header with the current play-point. If the RAP is closer, than it will 200 ok and deliver that. However, if the current playing point is closer then the server could respond with a error message. Thus indicating that it will continue with the previous request. The error class here isn't obvious, but I guess a 4xx as we have other pre-conditioned errors here.
Maybe 466 "Media precondition not meet". I don't think 412 fits the bill as it talks about the resource not being the correct one.

Feedback appreciated.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
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]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 05 Nov 2009 15:43:51 +0800

Hi Mike,

> I think it would be helpful to clarify the contexts in which RAPcond would be valid. For example, I don't think the described behavior makes sense if the seek point is backwards. (Something more li…

Yes, you are correct. It make sense only in the case when the closest
RAP with a forward seek, is prior to the servers current playout point.

> Although I think it could safely be ignored in the end-of-PLAY then new PLAY case, those scenarios probably should be thought through.

Yes, replacement PLAY is where I think it really makes sense. For resume
from pause I think there is also applicability as it would indicate that
you have not flushed your prior to pause context.

> And the distinction between client playback time and server current play time should be made explicit. I don't think it changes the scenarios at all, but in some cases it could mean you have more i…

Yes, this is all about the server side.

Cheers

Magnus Westerlund