Re: [AVTCORE] Question

Julius Friedman <juliusfriedman@gmail.com> Mon, 29 December 2014 00:43 UTC

Return-Path: <juliusfriedman@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0041AC3D5; Sun, 28 Dec 2014 16:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aqdxsON2p9q; Sun, 28 Dec 2014 16:43:43 -0800 (PST)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D58A1AC3C5; Sun, 28 Dec 2014 16:43:43 -0800 (PST)
Received: by mail-pa0-f52.google.com with SMTP id eu11so16377710pac.11; Sun, 28 Dec 2014 16:43:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yJ3Ux3xWmBHCMqxTpFNsG2GNC8fUeinpo1yeQOg16Ag=; b=Vc3lHPP/lFDTK9fLW8TQHgOvzPuvSuOS4xtv35nE1wsduu5ef0plbyRzJAT73SINio WZQ9DJ78CwlcFHu3Kh7rqTxwuXAavImVG+6fJ/U2ruWNnW2YIuo/EVudqHMpDk/qmYj6 EP5ncjWfd8dzH43xBYQfBo1fPE0+O16oG2Nj/SyhW1kJrOCWNtINOoHzwzlDnQXfHPLZ Q05/5BdYpSdIBNee3WC1NIPpowgJAdWGjbI5lGarO2/J8MKkG+bJNwN148TiKyY+biEu wPoFMUNKfbucu2a/7Ah3FXKylnsklLiNceoCIyT2S23DcFSXcLaKRifAeZ0tXFclKeV8 5vtQ==
MIME-Version: 1.0
X-Received: by 10.70.140.130 with SMTP id rg2mr86563969pdb.49.1419813822521; Sun, 28 Dec 2014 16:43:42 -0800 (PST)
Received: by 10.70.117.99 with HTTP; Sun, 28 Dec 2014 16:43:42 -0800 (PST)
In-Reply-To: <874msfcna5.fsf@hobgoblin.ariadne.com>
References: <CACFvNHWZdjmYYNu5DQnr53mzwjekU8wxwh+3yGRSTdgvN0Sm=w@mail.gmail.com> <874msfcna5.fsf@hobgoblin.ariadne.com>
Date: Sun, 28 Dec 2014 19:43:42 -0500
Message-ID: <CACFvNHXhFQe2CEKsv4q637SoGa-vKuhztN+a1ywK1ewU_Sa6KA@mail.gmail.com>
From: Julius Friedman <juliusfriedman@gmail.com>
To: "Dale R. Worley" <worley@ariadne.com>, avt@ietf.org, mmusic@ietf.org
Content-Type: multipart/alternative; boundary="001a1134c7c889e8cd050b502aeb"
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/HqF2Hauomuroo6FMOw28rHoqDpY
Subject: Re: [AVTCORE] Question
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Dec 2014 00:43:46 -0000

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

On Sun, Dec 28, 2014 at 7:28 PM, Dale R. Worley <worley@ariadne.com> wrote:

> Julius Friedman <juliusfriedman@gmail.com> writes:
> > 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?
>
> 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
>