Subject: [AVTCORE] Question

From: Julius Friedman <[email-masked]>
Date: Sun, 28 Dec 2014 00:24:18 -0500

I hope everyone had a great holiday!

I also hope the New Year is also as splendid for all of the members of the
IETF as it has ever been.

I am sorry to 'bother' again however while waiting for my responses on my
previous summary email 'On the following Errata' I ran across something I
had a question on which may need to be addressed further.

Rfc 2326 explicitly states that seeking can be disabled by not including
the end information in the range header.

What if I want to have the end but I don't want to allow seeking?

E.g. my clip is 10 minutes and I have already been playing for 3 and there
are 7 remaining; why can't I convey that and not allow seeking?

Obviously I can just return a BadRequest when a seek is performed or just
an OKAY to pretend like it's honored; but how can I convey in a standards
compliant manner that the stream is not seekable BEFORE the client attempts
the seek operation when also indicating the current and end times of the
media in question?

Thanks in advance and best wishes again!

Sincerely,
Julius Friedman

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 28 Dec 2014 19:28:18 -0500

> are 7 remaining; why can't I convey that and not allow seeking?

I'm no expert in RTSP, but reading the RFC, it appears that the server
indicates if seeking is allowed by the inclusion of the end-time:

    D.2.1 Basic Playback

     Client implementations may use the presence of length information
     to determine if the clip is seekable, and visibly disable seeking
     features for clips for which the length information is unavailable.

Exactly why the server cannot indicate the total media length without
implicitly stating the media is seekable, I don't know.  Perhaps it's
because any such media is theoretically seekable, since it must already
be instantiated as a stored data object.  Or perhaps it is because if
seeking is not implemented, the user interface is expected to not
display the "slider bar", and so there is no way to tell the user how
much time remains in the media:

     Client implementations may use the presence of length information
     to determine if the clip is seekable, and visibly disable seeking
     features for clips for which the length information is unavailable.
     A common use of the presentation length is to implement a "slider
     bar" which serves as both a progress indicator and a timeline
     positioning tool.

Perhaps referring to the mailing list discussion for this RFC would
reveal the answer.

In any case, why would we want to prevent seeking on a stored media
object?  I can see why if the media is an un-stored media stream, but in
that case, the software likely doesn't know the total length that the
media will have.

Dale

---

From: Julius Friedman <[email-masked]>
Date: Sun, 28 Dec 2014 19:43:42 -0500

Hello Dale, (et al)

I would like to address your response:

"In any case, why would we want to prevent seeking on a stored media
object?  I can see why if the media is an un-stored media stream, but in
that case, the software likely doesn't know the total length that the
media will have."

I will justify how "likely" this is as follows:

1) A Live 10 minute `media` which has been playing for 3 minutes, leaving
me 7 minutes in play but unable to seek.
   a) If the stream was stored or recorded this obviously wouldn't be an
issue

2) I have a server which requires authorization to seek but not to play.

3) I am a client and I have started playing and 'PAUSE' is not supported

4) I am a server re-streaming from a server where "Range" is not supported

"Perhaps referring to the mailing list discussion for this RFC would
reveal the answer."

Which mailing list is that? 'mmusic' they have also been addressed, several
times. I never get a response from them.

In any other case I hope all is well and that I haven't been marked as spam
or WORSE that there is something wrong with the list and my messages are
just not being received.

Anyway , thank you for your prompt response!

Sincerely,
Julius