Re: [MMUSIC] New Version Notification for draft-abhishek-mmusic-superimposition-grouping-00.txt(Internet mail)

"rabhishek(RohitAbhishek)" <rabhishek@tencent.com> Tue, 15 December 2020 14:59 UTC

Return-Path: <rabhishek@tencent.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8D03A11C2 for <mmusic@ietfa.amsl.com>; Tue, 15 Dec 2020 06:59:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tencent.com
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 qz_roEoR6pbF for <mmusic@ietfa.amsl.com>; Tue, 15 Dec 2020 06:59:23 -0800 (PST)
Received: from mail3.tencent.com (mail3.tencent.com [203.205.248.63]) (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 E1D843A11C0 for <mmusic@ietf.org>; Tue, 15 Dec 2020 06:59:21 -0800 (PST)
Received: from EX-SZ022.tencent.com (unknown [10.28.6.88]) by mail3.tencent.com (Postfix) with ESMTP id EF42494254 for <mmusic@ietf.org>; Tue, 15 Dec 2020 22:59:17 +0800 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tencent.com; s=s202002; t=1608044358; bh=TTbiky/ojkuPhLdCKXwNECK0lH03LwcCjQvGips5wUo=; h=From:To:Subject:Date:References:In-Reply-To; b=M1ntRenB1+LuBynOPKqsPyIB8aNJgLDX06UZSs12OdcJjxjz/LUYwvu/zzoOLiWQx I3luKFYupFaKkAOj+vdxbTabmIFgto0FEr0dhoDke2GqjKLTWzJUDodJ8b2Btz8INF N9Gov+HLP3aJlxJbiV1RdtVgx2Lw/vZQ0U1i2clI=
Received: from EX-US01.tencent.com (10.93.1.207) by EX-SZ022.tencent.com (10.28.6.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 15 Dec 2020 22:59:17 +0800
Received: from EX-US01.tencent.com (10.93.1.207) by EX-US01.tencent.com (10.93.1.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 15 Dec 2020 22:59:15 +0800
Received: from EX-US01.tencent.com ([fe80::2871:b384:ea95:2ddc]) by EX-US01.tencent.com ([fe80::2871:b384:ea95:2ddc%4]) with mapi id 15.01.2106.002; Tue, 15 Dec 2020 22:59:15 +0800
From: "rabhishek(RohitAbhishek)" <rabhishek@tencent.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] New Version Notification for draft-abhishek-mmusic-superimposition-grouping-00.txt(Internet mail)
Thread-Index: AQHW0LoGqdF2nsVG50uAFNA+ptmE1qn0/KMAgAFGLICAAPU1gA==
Date: Tue, 15 Dec 2020 14:59:15 +0000
Message-ID: <45A9CBE2-3166-4C49-B6FA-DF07FFF39DE3@tencent.com>
References: <160771931179.3111.1400354969020371031@ietfa.amsl.com> <BLAPR07MB75720867628E07B8C3D07F23F3CA0@BLAPR07MB7572.namprd07.prod.outlook.com> <AM0PR07MB3860502D06574BC64596665A93C90@AM0PR07MB3860.eurprd07.prod.outlook.com> <ac9b28ee-d9fe-93e2-2e14-6fe95df53ddf@alum.mit.edu> <28946d30-d203-9890-1048-5ceeaefc3c27@alum.mit.edu>
In-Reply-To: <28946d30-d203-9890-1048-5ceeaefc3c27@alum.mit.edu>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [9.45.201.55]
Content-Type: text/plain; charset="utf-8"
Content-ID: <63F7577DC0999F42B988A9666E3BD143@tencent.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/0ckAgWIlUz-ov7OnGYqBJe448sI>
Subject: Re: [MMUSIC] New Version Notification for draft-abhishek-mmusic-superimposition-grouping-00.txt(Internet mail)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Dec 2020 14:59:28 -0000

Thanks again Paul for your comments. I will make these updates in the next version.

Regarding point 2, I agree with you that the non-supporting device should treat these as independent media streams.

Best Regards,
Rohit 

On 12/14/20, 8:22 AM, "mmusic on behalf of Paul Kyzivat" <mmusic-bounces@ietf.org on behalf of pkyzivat@alum.mit.edu> wrote:

    Rohit,

    Here are a few more points I forgot:

    1) syntax

    In section 3 you repeat the syntax for the 'mid' attribute from RFC5888. 
    I guess you don't intend it to be normative, but it gave me that impression.

    I don't think you need to repeat the syntax here. It should be 
    sufficient to mention that you follow RFC5888 in use of the 'mid' 
    attribute to identify the media sections that are to be included in the 
    superposition.

    Similarly in section 5, I suggest that you only provide ABNF for the 
    additions to syntax required for your extension. Specifically:

       semantics =/ "superposition" <semantics as defined in RFC5888>

    (Everything else is inherited from RFC5888.)

    2) applicability

    Regarding the following in section 3:

        ... An application that receives a session
        description that contains "m" lines grouped together using "S"
        semantics MUST superimpose the corresponding media streams on top of
        the background media stream.

    You need to recognize that because this feature is an extension its 
    requirements can only apply to those that implement the extension. Its 
    best to call that out specifically.

    Also, please give some thought to what will happen a device supporting 
    this negotiates a session with a device that doesn't. The non-supporting 
    device will treat these as independent media streams. If that is a 
    problem for you then we need to discuss strategies for avoiding that 
    situation.

    3) differing size/resolution

    How the overlaying will work seems well defined if the image width and 
    height in pixels and pixel shape is the same for all the media streams 
    in the superposition group. But what if they aren't?

    I think the document should specify what should happen in such cases.

    	Thanks,
    	Paul

    On 12/13/20 3:54 PM, Paul Kyzivat wrote:
    > On 12/12/20 2:06 PM, Christer Holmberg wrote:
    >> Hi,
    >>
    >> A few comments (some of which I gave already previously):
    > 
    > Christer covered most of what I wanted to say. I'll just add a few 
    > tweaks below.
    > 
    >> Q1:
    >>
    >> In Section 1, where you talk about the limitations of the mechanism, 
    >> you should mention that CLUE must be used something more "fancy" is 
    >> needed.
    >>
    >> ---
    >>
    >> Q2:
    >>
    >> In Section 3, you require a specific order of the m- lines in the SDP. 
    >> I think SDP explicitly says that the order of m- lines is not 
    >> relevant. Also, I know that parsers may change the orders of the m- 
    >> lines.
    >>
    >> (I also think that any counting should start from 1, not 0)
    >>
    >> My suggestion would be to have an explicit "order" attribute instead.
    > 
    > I think it would be acceptable to use the order of the tokens in the 
    > a:group line to define the ordering of the "layers". The "lowest" layer 
    > would then be the background on which the others are overlain. (Whether 
    > the lowest layer is the first or last in the list is TBD.)
    > 
    >> ---
    >>
    >> Q3:
    >>
    >> The example in Section 6 talks about "a background video". But, this 
    >> background video is not described in the SDP.
    >>
    >> Related to that, if the SDP describes multiple "background videos", 
    >> you need to describe how you map superimposed videos to a specific 
    >> background video.
    >>
    >> Based on the text in Section 3 (see Q2), I am not sure whether the 0th 
    >> m- line is supposed to be the background video, but the text in 
    >> Section 6 says that both m- lines are for superimposed video streams.
    > 
    > See my comment above.
    > 
    > The background layer would presumably have a transparency of zero.
    > 
    > (It would also be good to specify that if the transparency attribute is 
    > omitted it defaults to zero.)
    > 
    >> ---
    >>
    >> Q4:
    >>
    >> What happens to the superimposed videos if I disable/remove/mute the 
    >> background video?
    >>
    >> ---
    >>
    >> Q5:
    >>
    >> This is editorial, but please call the group attribute something else 
    >> than just "S". "supim", "spim" or something :)
    > 
    > Yes please. "S" is way to cryptic.
    > 
    >      Thanks,
    >      Paul
    > 
    >> Regards,
    >>
    >> Christer
    >>
    >>
    >>
    >> -----Original Message-----
    >> From: mmusic <mmusic-bounces@ietf.org> On Behalf Of Rohit Abhishek
    >> Sent: lauantai 12. joulukuuta 2020 0.28
    >> To: mmusic@ietf.org
    >> Subject: [MMUSIC] FW: New Version Notification for 
    >> draft-abhishek-mmusic-superimposition-grouping-00.txt
    >>
    >> Dear All,
    >>
    >> A new version of the draft “SDP Superimposition Grouping framework” 
    >> has been uploaded.
    >> We have changed the name from  “SDP Overlay Grouping framework for 
    >> immersive telepresence media streams” to  “SDP Superimposition 
    >> Grouping framework” as the previous name wasn’t an accurate 
    >> description of the content. Therefore, we had to start from version 00.
    >>
    >> Thank you all for the comments/suggestions on the previous draft.
    >> We have tried to address them in this version. Specifically, a 
    >> transparency attribute and an informative Section on relationship with 
    >> CLUE has been added.
    >>
    >> Comments/Questions/Feedbacks are welcome.
    >>
    >> Best Regards,
    >> Rohit
    >>
    >> On 12/11/20, 12:41 PM, "internet-drafts@ietf.org" 
    >> <internet-drafts@ietf.org> wrote:
    >>
    >>
    >>      A new version of I-D, 
    >> draft-abhishek-mmusic-superimposition-grouping-00.txt
    >>      has been successfully submitted by Rohit Abhishek and posted to the
    >>      IETF repository.
    >>
    >>      Name:        draft-abhishek-mmusic-superimposition-grouping
    >>      Revision:    00
    >>      Title:        SDP Superimposition Grouping framework
    >>      Document date:    2020-12-11
    >>      Group:        Individual Submission
    >>      Pages:        8
    >>      URL:            
    >> https://www.ietf.org/archive/id/draft-abhishek-mmusic-superimposition-grouping-00.txt 
    >>
    >>      Status:         
    >> https://datatracker.ietf.org/doc/draft-abhishek-mmusic-superimposition-grouping/ 
    >>
    >>      Htmlized:       
    >> https://datatracker.ietf.org/doc/html/draft-abhishek-mmusic-superimposition-grouping 
    >>
    >>      Htmlized:       
    >> https://tools.ietf.org/html/draft-abhishek-mmusic-superimposition-grouping-00 
    >>
    >>
    >>
    >>      Abstract:
    >>         This document defines semantics that allow for signaling a new 
    >> SDP
    >>         group "S" for superimposed media in an SDP session.  The "S"
    >>         attribute can be used by the application to relate all the
    >>         superimposed media streams enabling them to be added as an 
    >> overlay on
    >>         top of any media stream.  The superimposition grouping 
    >> semantics is
    >>         required, if the media data is separate and transported via 
    >> different
    >>         sessions.
    >>
    >>
    >>
    >>
    >>      Please note that it may take a couple of minutes from the time of 
    >> submission
    >>      until the htmlized version and diff are available at tools.ietf.org.
    >>
    >>      The IETF Secretariat
    >>
    >>
    >> _______________________________________________
    >> mmusic mailing list
    >> mmusic@ietf.org
    >> https://www.ietf.org/mailman/listinfo/mmusic
    >> _______________________________________________
    >> mmusic mailing list
    >> mmusic@ietf.org
    >> https://www.ietf.org/mailman/listinfo/mmusic
    >>
    > 
    > _______________________________________________
    > mmusic mailing list
    > mmusic@ietf.org
    > https://www.ietf.org/mailman/listinfo/mmusic

    _______________________________________________
    mmusic mailing list
    mmusic@ietf.org
    https://www.ietf.org/mailman/listinfo/mmusic