Re: [Moq] Scope of MOQ and ULL Streaming
Bernard Aboba <bernard.aboba@gmail.com> Mon, 06 February 2023 17:25 UTC
Return-Path: <bernard.aboba@gmail.com>
X-Original-To: moq@ietfa.amsl.com
Delivered-To: moq@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844A3C14CEE3 for <moq@ietfa.amsl.com>; Mon, 6 Feb 2023 09:25:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcb8O31BGyqb for <moq@ietfa.amsl.com>; Mon, 6 Feb 2023 09:25:05 -0800 (PST)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8EFBC14F731 for <moq@ietf.org>; Mon, 6 Feb 2023 09:25:04 -0800 (PST)
Received: by mail-ej1-x62e.google.com with SMTP id hx15so36188210ejc.11 for <moq@ietf.org>; Mon, 06 Feb 2023 09:25:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=x/vOERLIpqnHOhz2qEBL6qCO6d+eiCPHDwWgl3H9xCs=; b=pwA78mBpAUkNYmThcQMpRUjEWTtcJ/soJMK1CMcA4NJWFJsvIF2d0GDbpshMaJGO02 0Ci97P17RMTzRm7dQ4YsCfWx7jxrEawL5Dj9VQMQP3fmvzliMFx8tcPODLB5FS+xn0dz 5RxuZ3XkS0txr72lWFn3iXuMRJlmwbEJT2eJdnrNfq0jhGeFoS502RbPfUqCYqp7Fkcy waYou0sEy+KbJFrivt5YgrHTD4LJEGAQCA9Ztq0ZdAR68fcElLvPnzNsExxxXVZMCN7Y 3iG+jaxG8p4UBJVC76iL9RuIjYpFGAn6sHA2Q7WXqa1kTbJxac0WS/zahMGqJwkKVPZP QrlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=x/vOERLIpqnHOhz2qEBL6qCO6d+eiCPHDwWgl3H9xCs=; b=Nl2ZeO97uGsnkNAJkDlJtn9JOI/KTVorQyMG3xn4qQngccwgTlfmw0Lw+kmgGiuUSe RgaNXWYwwDxLVwBaiowNpeTKY5B5u6SnP/L75T/k8ZHLeWx6ahsD9JPtkuUttr/Uynav wOCVXhq3DI4SRtclsMMs9c8OqxQEGanR1Ui10xWNXf/V/X5nvIHIzdTqBYzcBPDgs6GE EJY+VlZZxeN04/C00KXU4unjhsVhNrccK4qsHy+i74b7WHP6KfETh3GNC3BpKoWh1/46 AfnRfMXNEWHCRd5Zhi4vEznQs7cqAG2WQqHD0QXlT9vS6O+NTzxvyoPHni2MFBP2gok2 0X5w==
X-Gm-Message-State: AO0yUKXH8MIzmZbkdvJw+FnuN3USTFF3EH1Hkxz4wfApNtzshVlr9jkA FnvrTHfQZMMB34FK/eOpMyZIX0TPCUb/IOOinmg=
X-Google-Smtp-Source: AK7set82y1kqlewYku07OlkzQmMKtGieAtsadxvgRkSPG6/ziM9luQSYTvEKgcN2GDgEmI55XnyL43Xp8aB3CuvWXZE=
X-Received: by 2002:a17:906:b844:b0:878:54d2:1080 with SMTP id ga4-20020a170906b84400b0087854d21080mr25305ejb.98.1675704303078; Mon, 06 Feb 2023 09:25:03 -0800 (PST)
MIME-Version: 1.0
References: <CANG3SPyuA=pThgpZCwUYT9KjGT0xogonruQpSiSiGwgcRATknw@mail.gmail.com>
In-Reply-To: <CANG3SPyuA=pThgpZCwUYT9KjGT0xogonruQpSiSiGwgcRATknw@mail.gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 06 Feb 2023 09:24:51 -0800
Message-ID: <CAOW+2dvRMPgO2Lo5dYjCAzKFQj09JH3sEt62zaiz4U379k5uMw@mail.gmail.com>
To: nathan.burr@paramount.com
Cc: moq@ietf.org
Content-Type: multipart/related; boundary="000000000000bbf56f05f40b4f41"
Archived-At: <https://mailarchive.ietf.org/arch/msg/moq/rjJYF58gchgpDxfYV08GXNJsfFU>
Subject: Re: [Moq] Scope of MOQ and ULL Streaming
X-BeenThere: moq@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Media over QUIC <moq.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/moq>, <mailto:moq-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/moq/>
List-Post: <mailto:moq@ietf.org>
List-Help: <mailto:moq-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/moq>, <mailto:moq-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Feb 2023 17:25:09 -0000
Nate said: "Some discussions around content protection and WebCodecs: https://github.com/w3c/webcodecs/issues/41" [BA] You'll notice that in addition to Issue 41 (filed early in WebCodecs development), there is also Issue 483 <https://github.com/w3c/webcodecs/issues/483>, a call for "Early Adopters" of WebCodecs DRM support. Nobody came forward in response to that call. Typically, developers who move from MSE to WebCodecs do so because they do not require DRM and in the process, they typically move from containerized media to uncontainerized (e.g. what has been called "raw media", but also includes some metadata, such as timestamps). For those developers (which include quite a few of the MoQ use cases), containerization does not provide value. On Mon, Feb 6, 2023 at 9:05 AM Nathan Burr <nathan.burr@paramount.com> wrote: > *Discussion #1:* > > I've spent a bit of time trying to wrap my head around what MOQ is and I > feel like this needs to be discussed further. I've seen everything from VR, > Conferencing, ULL Broadcasting and gaming as possible use cases. I feel > like this is an important discussion because MOQ could be a base layer spec > that supports all of these. But that means possibly the need for more > specs. Such as VR ov MOQ or ULL Streaming over MOQ. Or it could be a Spec > that is more specific to just one thing. The original work around WARP > seemed to lean more towards ULL Streaming while RUSH leaned more towards VR > and gaming. > > So where does MOQ fit into all of this? Maybe this has already been > discussed and I'm just missing context.. > > My expertise is around ABR Streaming. So I'll be providing more feedback > on that side of the conversation of where I would like things to go. > > *Discussion #2:* > > What is the target latency? Maybe that depends on the answer to Discussion > #1. For ULL Streaming I would think somewhere between 500ms - 2.5s. > > *Discussions around ULL Streaming involving MOQ:* > > [image: image.png] > > In my opinion, MOQ should be a stateless forwarding machine. I would like > to do two basic types of requests. > > - Subscribe > - I picture this is something similar to how MQTT works with > topics. Subscribe to a topic or sub topics and use wildcards. Example: > > Big_Buck_Bunny/VideoTrack{N}/Representation{N}/ > Big_Buck_Bunny/AudioTrack{N}/Representation{N}/ > Big_Buck_Bunny/SubtitleTrack{N}/Representation{N}/ > - GET > - I feel like this would still be important to discover information > about the channel without having to subscribe. IMO each topic should have > an associated metadata endpoint. that describes the channel, track, > representation. This way a client can get stream details without needing > information from a manifest. > > Relaying is probably out of scope for MOQ. Looks like some are working on > that process. But I would imagine some sort of smart relaying where you > only relay what is being subscribed to down the subscription chain. > > In order to support channel composition (inserting ads, blackout, slate, > scheduling, switching channels, PiP, contributor feed, commentary, etc.) I > feel like we will still need a manifest of some sort that contains > different metadata from different assets and channels. In this scenario > having the ability to share a session ID between the manifest and transport > would be important. This would probably fall under some of the other AuthZ > type of discussions. > > Session ID would be needed to make sure to terminate any subscriptions > after their subscription has expired. > > *Next Gen ULL Streaming Wish List:* > > - "Synchronization Tracks" for quick channel switching and recovery. > https://media.idlab.ugent.be/keyframe-insertion-electronics > - AV1 - Switch Frames > - DRM - EME requires ISOBFF. Would be nice if EME supported raw ES. > Some discussions around content protection and WebCodecs: > https://github.com/w3c/webcodecs/issues/41 > Could make it so we transport CMAF over MOQ or make a polyfill around > EME/MediaSource that muxes content into ISOBFF format. as long as the ES > conforms to CENC spec. > - No more polling. Updates to the manifest are streamed. > > > -Nate > > > > -- > Moq mailing list > Moq@ietf.org > https://www.ietf.org/mailman/listinfo/moq >
- [Moq] Scope of MOQ and ULL Streaming Nathan Burr
- Re: [Moq] Scope of MOQ and ULL Streaming Bernard Aboba
- Re: [Moq] Scope of MOQ and ULL Streaming Shihang(Vincent)
- Re: [Moq] Scope of MOQ and ULL Streaming Nathan Burr
- Re: [Moq] Scope of MOQ and ULL Streaming Spencer Dawkins at IETF
- Re: [Moq] Scope of MOQ and ULL Streaming Luke Curley
- Re: [Moq] Scope of MOQ and ULL Streaming Spencer Dawkins at IETF
- Re: [Moq] Scope of MOQ and ULL Streaming Nathan Burr
- Re: [Moq] Scope of MOQ and ULL Streaming Bernard Aboba
- Re: [Moq] Scope of MOQ and ULL Streaming Ali C. Begen
- Re: [Moq] Scope of MOQ and ULL Streaming Bernard Aboba
- Re: [Moq] Scope of MOQ and ULL Streaming Ali C. Begen
- Re: [Moq] Scope of MOQ and ULL Streaming Suhas Nandakumar
- Re: [Moq] Scope of MOQ and ULL Streaming David Fernández
- Re: [Moq] Scope of MOQ and ULL Streaming Bernard Aboba
- Re: [Moq] Scope of MOQ and ULL Streaming Spencer Dawkins at IETF
- Re: [Moq] Scope of MOQ and ULL Streaming Bernard Aboba
- Re: [Moq] Scope of MOQ and ULL Streaming Luke Curley
- Re: [Moq] Scope of MOQ and ULL Streaming Behcet Sarikaya
- Re: [Moq] Scope of MOQ and ULL Streaming Charles 'Buck' Krasic
- Re: [Moq] Scope of MOQ and ULL Streaming Nathan Burr
- Re: [Moq] Scope of MOQ and ULL Streaming Suhas Nandakumar
- Re: [Moq] Scope of MOQ and ULL Streaming Spencer Dawkins at IETF