Subject: [MMUSIC] RTSP: New Range header construct

From: Sean Sheedy <[email-masked]>
Date: Fri, 21 Nov 2008 11:51:26 -0600

I've (finally) added a new construct for Range that allows simple skip 
behavior (e.g., skipping 30 seconds over a commercial).  I proposed this 
late last year, and it was met with resounding silence, which I take as 
consent:

http://www.ietf.org/mail-archive/web/mmusic/current/msg06474.html

The actual text added to the draft:

-------------

4.5.  Normal Play Time

    The special constants "current+" and "current-" followed by a decimal
    fraction can be used to indicate a position relative to the currently
    playing location in the presentation.  The decimal fraction is always
    expressed as seconds to the left of the decimal point and fractions
    of a second to the right. "current+" indicates a position beyond the
    currently playing location, while "current-" indicates a position
    before the currently playing location.  If a "current+" position
    resolves to a position beyond the end of the media, it MUST be
    treated as equivalent to end of media.  If a "current-" position
    resolves to a position before the beginning of media (that is, it
    would result in a negative value), it MUST be treated as equivalent
    to NPT 0.0.
    [...]
       The "current+" and "current-" constants allow for skip semantics
       without additional round trips to the server to obtain the
       currently playing location.

4.6.  Absolute Time

    The special constants "current+" and "current-" may be used with
    absolute time in a manner similar to that of normal play time (NPT).
    As with NPT, the offset from the currently playing location is
    specified as decimal fraction in seconds.

13.5.1.  End-of-Stream

    The server MUST NOT use the "now", "current+" or "current-" constants
    in the Range header; it MUST use the actual numeric end position in
    the proper timescale.

13.6.  PAUSE

    Any play-request including symbolic values, such as the NPT
    timescale's "now", "current+" or "current-", MUST be resolved into
    the actual stream position of the pause point.

20.1.  Base Syntax

    npt-time         =  "now" / npt-sec / npt-hhmmss / npt-rel
    npt-sec          =  1*DIGIT [ "." *DIGIT ]
    npt-rel          =  ( "current+" / "current-" ) npt-sec

    utc-time         =  ( ( utc-date "T" utc-clock "Z" ) / npt-rel )

-------------

Cheers,
Sean

~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--
Sean Sheedy
Staff System Software Engineer, Media and Communications Systems
[email-masked] | 503-531-6427 (Phone)
~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--~--

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

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 21 Nov 2008 20:48:33 +0200

> late last year, and it was met with resounding silence, which I take as

I surely don't agree with this. First, you can already "skip" parts of the 
media with the already bloated Range header. Second, removal of ads is 
morally if not legally questionable. Third, only an engineer UI could control 
such a feature.

-- 
Rémi Denis-Courmont

---

From: "HAAS Christian" <[email-masked]>
Date: Mon, 24 Nov 2008 13:55:45 +0100

Hello!

From: Sean Sheedy
> late last year, and it was met with resounding silence, which I take as 

I don't see the reason to avoid one extra round trip for this probably rarely
used feature. I'd rather go into the direction of a fast-forward (Scale
header) to have more usage options if the clients are annoyed to query the
server and perform a jump.

Although I don't have that much problems with a list of ranges in one header
as it is now, I might get them when these relative positions are allowed as
well; The following, valid, header would give me some headaches:

Range: current+10-current+20, current-5-, current-30-current-20

Do all these 'current's refer to the position at the time of arrival of this
message, or are they to be resolved whenever one range entry is completed?
(The latter case is the one giving me headaches, because the I'd have to
handle yet another case next to 'now', 'start/end', 'abs-pos')

I know, this example does not make that much sense, but from the point of
implementation, I need to know what to do if someone found some
application...

Also, I still don't know the full code of conduct, but for a change based on
info with a certain age I'd have hoped to receive some sort of warning :)

Kind regards,
ch
____________________________________________________
Christian Haas
Team DIVOS, Software Engineer
FREQUENTIS AG

Innovationsstraße 1, 1100 Vienna, Austria
Phone   +43-1-811 50 - 8353
Mobile   +43-664-60 850 - 8353
Fax       +43-1-811 50 - 77 8353
Web      www.frequentis.com
E-Mail    [email-masked]
 
Handelsgericht Wien (Vienna Commercial Court): FN 72115 b
DVR 0364797, ATU 14715600
____________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser E-Mail sind nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

---

From: Sean Sheedy <[email-masked]>
Date: Mon, 24 Nov 2008 13:02:58 -0800

> server and perform a jump.

I already have a customer who uses repeated skips in place of visual
fast forward or rewind.  With the current RTSP semantics, it requires
two round trips for each skip.  For their use case, saving the extra
round trip is significant.  (BTW, supporting this customer was the
initial impetus for the proposal.)

> handle yet another case next to 'now', 'start/end', 'abs-pos')

"current" is intended to be the current play location at the time of the
arrival of the message.  I should clarify this in the draft.

> implementation, I need to know what to do if someone found some

Shaking out weird corner cases early is always good.

Regards,
Sean

---

From: Sean Sheedy <[email-masked]>
Date: Mon, 24 Nov 2008 13:09:50 -0800

> > Range: current+10-current+20, current-5-, current-30-current-20

It just occurred to me that the aforementioned customer could, in fact,
use syntax similar to your example for their repeated skips in a single
request.

Regards,
Sean

---

From: Sean Sheedy <[email-masked]>
Date: Mon, 24 Nov 2008 13:10:23 -0800

> morally if not legally questionable. Third, only an engineer UI could control

As mentioned in another message, I already have a customer who uses
repeated skips in place of visual fast forward or rewind.  How would
they accomplish this with the existing Range features without at least 2
round trips to the server?

Regards,
Sean

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 24 Nov 2008 23:16:51 +0200

Le lundi 24 novembre 2008 23:10:23 Sean Sheedy, vous avez écrit :
> > > behavior (e.g., skipping 30 seconds over a commercial).  I proposed
> > > this late last year, and it was met with resounding silence, which I
> > > take as consent:
> >
> > I surely don't agree with this. First, you can already "skip" parts of
> > the media with the already bloated Range header. Second, removal of ads
> > is morally if not legally questionable. Third, only an engineer UI could
> > control such a feature.
>

What's wrong with two round trips? Adding complexity that's useless in 99,999% 
cases to optimize away one round trip sounds like a very wrong tradeoff. RTSP 
is sufficiently bloated already.

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "HAAS Christian" <[email-masked]>
Date: Tue, 25 Nov 2008 11:24:55 +0100

Hello!

From: Rémi Denis-Courmont
> is sufficiently bloated already.

How about the approach of using a new form of range-spec, which can be
optional or even an extension? (i.e.: Instead of
npt=current+10.0-current+20.0 have a rel-npt=+10.0-+20.0 ?)

Regards,
ch

Innovationsstraße 1, 1100 Vienna, Austria
Phone   +43-1-811 50 – 8353
Mobile   +43-664-60 850 – 8353
Fax       +43-1-811 50 – 77 8353
Web      www.frequentis.com
E-Mail    [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 28 Nov 2008 16:02:19 +0100

> initial impetus for the proposal.)

Actually after having read the comments about this and thinking I don't
understand why current really is needed. A client should know what media
to request without going to the server to request current playout time.
The client already knows what NPT time it is currently displaying for
the user. So if the user hits the skip button the client takes the time
add the skip time it implements and send a new PLAY request. It anyway
needs to flush some content from its buffer so the discrepancy should
not be a problem.

Sean, can you please explain what the issue is with having the client
keeping track of the current display position?

Cheers

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