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

["SEVERA Mike" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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:
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  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic