Re: Multicast streaming video client

Ross Finlayson <finlayson@live555.com> Thu, 26 January 2017 00:58 UTC

Return-Path: <finlayson@live555.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534E1129410 for <ietf@ietfa.amsl.com>; Wed, 25 Jan 2017 16:58:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
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 UCN-wlLd8Efp for <ietf@ietfa.amsl.com>; Wed, 25 Jan 2017 16:58:50 -0800 (PST)
Received: from ns.live555.com (ns.live555.com [4.79.217.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452291293FD for <ietf@ietf.org>; Wed, 25 Jan 2017 16:58:50 -0800 (PST)
Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.15.2/8.15.2) with ESMTP id v0Q0wlBU064768 for <ietf@ietf.org>; Wed, 25 Jan 2017 16:58:48 -0800 (PST) (envelope-from finlayson@live555.com)
X-Authentication-Warning: ns.live555.com: Host localhost.live555.com [127.0.0.1] claimed to be [127.0.0.1]
From: Ross Finlayson <finlayson@live555.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Multicast streaming video client
Date: Thu, 26 Jan 2017 13:58:47 +1300
References: <CAMm+Lwhqfxk2GWVuGiH4uWmfKbGi0H9PAAZi7+FAfTnePEwQPg@mail.gmail.com>
To: IETF Discussion Mailing List <ietf@ietf.org>
In-Reply-To: <CAMm+Lwhqfxk2GWVuGiH4uWmfKbGi0H9PAAZi7+FAfTnePEwQPg@mail.gmail.com>
Message-Id: <4968B332-45D9-42A9-92EB-F26E5DBC2F47@live555.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/a_xiu-R9ddrL73FmPp_UpuyBw14>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jan 2017 00:58:51 -0000

> Imagine that there is a video streaming client that takes its content stream from a combination of a multicast channel and a unicast channel. At a coarse level, the client receives packets over the multicast link and requests retransmission over the unicast.

There was some very preliminary work recently presented to the (RTP) “PAYLOAD” working group describing a proposal to optimize a HTTP Adaptive Streaming video infrastructure (i.e., "HTTP Live Streaming" or “DASH”) when a live video event is carried over a multicast network.  The proposal currently has lots of issues to be fleshed out, and (AFAIK) it’s still unclear whether it'll become a working group - but if you’re interested, see the thread here:
	https://mailarchive.ietf.org/arch/search/?email_list=payload&qdr=y&gbt=1&index=N4qSH2GcGVdMwDUNbWEdDCy5bjs

    Ross.