Subject: [MMUSIC] Backwards range and negative scale clarification (bugs 533691, 513880)

From: Aravind Narasimhan <[email-masked]>
Date: Wed, 16 Apr 2003 11:55:21 -0400

Hi Folks,    
In my attempt to clarify the negative scale and backwards range issues 
brought up by bugs http://rtsp.org/bug533691 &  
http://rtsp.org/bug513880 some issues surfaced with regards to the 
current definition of ranges in the spec.  I wanted to discuss these 
issues before sending off my write up.

Issue 1:
---------
Range is defined in RTSP as a half open interval.  To quote from draft-03

Ranges are half-open intervals, including the lower point, but
excluding the upper point. In other words, a range of a-b starts
exactly at time a, but stops just before b.

Now the resolution that we came up with for this issue was that we would 
always go from the first number in the range to the last number in the 
range.  So for example, if the range of a PLAY request was
    Range: npt=10-15
we would go from 10 -> 15, where the play would stop just before 15.  If 
the request had  range and scale headers as the following:
    Scale: -1
    Range: npt=15-10
the play would go backwards and we would go from 15 -> 10.

Now the question is how do we interpret the half-open rule.  I.e.  Do we 
stop at 10 or just before we reach 10 (i.e. npt > 10) in the backwards 
scenario above? The latter seems like they way to interpret the half - 
open rule.  But if we interpret it that way, then how do we deal with 
the following:
    Scale: -1
    Range: npt=15-0
We would have to stop before 0 and there would be no way to get to 0 
since you cannot specify negative ranges.  Obviously the way to get 
around this is to do the following:
    Scale: -1
    Range: npt=15-
But this doesn't seem too clean to me.

The other option is to say that  backwards ranges are always closed 
ranges.  This, however, makes ranges a bit more inconsisted and harder 
to deal with.

Issue 2:
----------
The other thing that doesn't make sense with backwards ranges are the 
Clock ranges.  For example:
    Scale: -1
    Range: clock=20030416T000000.00Z-20030101T000000.00Z
makes no sense because clocks cant go backwards.

So I propose that Scale can only be negative for ranges that deal with 
relative time rather than absolute time.

---

From: Aravind Narasimhan <[email-masked]>
Date: Mon, 28 Apr 2003 11:56:50 -0400

Hey Magnus,
Thanks for the excellent summary of our concall. 

Another potential way to resolve the situation with the closed/openeness 
of ranges headers that we haven't discussed before is to include another 
field, "type=" (similar to the "time=" field) in the range header which 
explicitly defines the exact nature of the range header.  For example:

PLAY rtsp://foo RTSP/1.0
Session: bar
Range: ntp=5-10; type=1

where we have a predefined set of types:

    0 = default RFC 2326 behavior
    1 = closed on both ends
    2 = open on both ends
    3 = start open, end closed

Obviously, we dont need to specify more types than absolutely necessary.

Now if the type is not specified in a play request, we can specify that 
the default behavior as specified in RFC 2326 with halfopen interval 
will be followed.  However, for more precise handling of the Range, the 
type would have to be specified.. .  

I think this is a good compromise without having to make corner cases as 
is option A below, or changing the semantic of Range completely as in 
option C below.

more comments inline:

Magnus Westerlund wrote:

> Hi,
>
> This was discussed at the last telecon. There was no conclusions on 
> how to solve it. There where three proposals. I also give some of my 
> personal views on the matter.
>
> A. Make an exception at 0. So that any half open end point that 
> includes 0 actually is closed at 0. The only real problem with having 
> a open end interval when playing backwards is the end point a 0, as we 
> can't give negative numbers in npt scale. One can of course leave the 
> interval without a second value. However if a server in a response 
> would like to tell that it is playing to 0 it is still not good.
>
>
> B. Make the range header interpretation depend on scale header sign. 
> For negative scale the range header would go from a open to a closed 
> point. Example Range: Scale=-1 npt=10-5 would mean: play from just 
> before 10 to and including 5. However I see some problem with trying 
> to start playback with an open interval. Where is the differnece 
> between a point and very, very close to it. Also how does one handle 
> RTP-Info if the synchronization point is not defined.

I dont think that the RTP-Info causes a problem.  The RTP-Info is 
returned for the actual range this is going to be played back.  This 
range needs to go in PLAY response and that RTP-Info will then 
correspond to that range start time.

> C. Make the Range header interval closed in both ends. The argument 
> was that we don't need the distinction provided by an half open 
> interval and by closing it in both ends one forces the server to play 
> the whole given interval and the client trims any excess. There are 
> some backwards considerations in this case.
>
>
> To the second issue: I think there is reasons to play media with real 
> time scale backwards. My favourite example is the Surveilance video 
> storage server. This media is of course indexed using real world 
> clock. So if you desire to view the surveilance tape backwards then 
> you need it.

Ok I can kind of buy this argument.  However, I think it is important to 
call this out in the spec. or in an appendix to the spec, because I'm 
sure it will be many people's first assumption to assume that time 
cannot travel backwards.

>
> Any more comments?
>
> Best  Regards
>
> Magnus
>
>
> Aravind Narasimhan wrote:
>
>> Hi Folks,    In my attempt to clarify the negative scale and 
>> backwards range issues brought up by bugs http://rtsp.org/bug533691 
>> &  http://rtsp.org/bug513880 some issues surfaced with regards to the 
>> Now the resolution that we came up with for this issue was that we 
>> would always go from the first number in the range to the last number 
>> in the range.  So for example, if the range of a PLAY request was
>>     Range: npt=10-15
>> we would go from 10 -> 15, where the play would stop just before 15. 
>>  If the request had  range and scale headers as the following:
>>     Scale: -1
>>     Range: npt=15-10
>> Now the question is how do we interpret the half-open rule.  I.e.  Do 
>> we stop at 10 or just before we reach 10 (i.e. npt > 10) in the 
>> backwards scenario above? The latter seems like they way to interpret 
>> the half - open rule.  But if we interpret it that way, then how do 
>> we deal with the following:
>>     Scale: -1
>>     Range: npt=15-0
>> ranges.  This, however, makes ranges a bit more inconsisted and 
>> harder to deal with.
>>
>> Issue 2:
>> ----------
>> So I propose that Scale can only be negative for ranges that deal 
>> with relative time rather than absolute time.
>>
>>
>

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic