[Hls-interest] Allow URI changes
Philipp <philipp+ietf@bureaucracy.de> Sat, 29 August 2020 19:53 UTC
Return-Path: <philipp@bureaucracy.de>
X-Original-To: hls-interest@ietfa.amsl.com
Delivered-To: hls-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021C93A0FAB for <hls-interest@ietfa.amsl.com>; Sat, 29 Aug 2020 12:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] 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 ClfE4nTsZjWA for <hls-interest@ietfa.amsl.com>; Sat, 29 Aug 2020 12:53:30 -0700 (PDT)
Received: from bureaucracy.bureaucracy.de (bureaucracy.bureaucracy.de [IPv6:2a02:180:1:1::517:b8d]) (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 03D563A0FAA for <hls-interest@ietf.org>; Sat, 29 Aug 2020 12:53:29 -0700 (PDT)
Received: from hell (localhost [::1]) by bureaucracy.bureaucracy.de (OpenSMTPD) with ESMTP id 3799a8c9 for <hls-interest@ietf.org>; Sat, 29 Aug 2020 21:53:25 +0200 (CEST)
Received: from localhost (hell [local]) by hell (OpenSMTPD) with ESMTPA id 23fa874d for <hls-interest@ietf.org>; Sat, 29 Aug 2020 19:53:25 +0000 (UTC)
From: Philipp <philipp+ietf@bureaucracy.de>
To: hls-interest@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <18147.1598730805.1@localhost>
Date: Sat, 29 Aug 2020 21:53:25 +0200
Message-Id: <7c59d1234eb86e37@hell>
Archived-At: <https://mailarchive.ietf.org/arch/msg/hls-interest/plfSyPmoVyvgv6AkFWmMH5iQog0>
Subject: [Hls-interest] Allow URI changes
X-BeenThere: hls-interest@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions about HTTP Live Streaming \(HLS\)." <hls-interest.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hls-interest>, <mailto:hls-interest-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hls-interest/>
List-Post: <mailto:hls-interest@ietf.org>
List-Help: <mailto:hls-interest-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hls-interest>, <mailto:hls-interest-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Aug 2020 19:57:58 -0000
Hi I currently write a HLS Loadbalancer. The idea is to change the URI of the Media Segments, to select which client should load the Media Segments from which server. This might lead to change the URI of Media Segments for two causes: 1. Policy changes It might be necesarry change the server of a client during runtime of the stream. Yes the server could track the last segment number he deliverd to a client. This might lead to playback issues, depending on the reason the policy changed. Also this directly leads to the secound cause. 2. Lost of client tracking There are some edge cases the server don't recognice the client. In this case the server might give the client an other URI for the same Media Segment. Unfortunately section 6.1.2 don't allow to change the URI of a Media Segment and sections 6.3.4 say a client should halt playback if he detects a changed URI. I propose for the next version of the standard, to allow the server to change the URI and force the client to handle a changed URI in a sane way. So the client must not reload already loaded segments and must not stop loading already started downloads, but should use the new URI for new or restarted downloads. Philipp
- [Hls-interest] Allow URI changes Philipp
- Re: [Hls-interest] Allow URI changes Roger Pantos
- Re: [Hls-interest] Allow URI changes Philipp
- Re: [Hls-interest] Allow URI changes Roger Pantos