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

"rabhishek(RohitAbhishek)" <rabhishek@tencent.com> Tue, 19 January 2021 07:58 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 68F1B3A12B3 for <mmusic@ietfa.amsl.com>; Mon, 18 Jan 2021 23:58:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 TV4YT39LM8yd for <mmusic@ietfa.amsl.com>; Mon, 18 Jan 2021 23:58:02 -0800 (PST)
Received: from mail1.tencent.com (mail1.tencent.com [203.205.248.43]) (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 2C69B3A12B6 for <mmusic@ietf.org>; Mon, 18 Jan 2021 23:58:01 -0800 (PST)
Received: from EX-SZ022.tencent.com (unknown [10.28.6.88]) by mail1.tencent.com (Postfix) with ESMTP id D811A5A124 for <mmusic@ietf.org>; Tue, 19 Jan 2021 15:57:58 +0800 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tencent.com; s=s202002; t=1611043078; bh=ZApplqMXRqZRNm133i9AEoYRXBIqwFW4MGOGo1zju04=; h=From:To:Subject:Date:References:In-Reply-To; b=HPOfv1nSdzD7sjZZr+5+CxkP7TIaCnFegvgm+yp6sSE7h3MfP+dA6rc1pTPYTl18r NZpex/JtJPjKrkIgH3uHaGsap7MjDQyHaFdBrbafVG179pfDYyBKNe4BT25dxod876 SARf46gDaZZb3HfcqsXoXpxrrS0nRsf1cqpR8+AE=
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, 19 Jan 2021 15:57:58 +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, 19 Jan 2021 15:57:56 +0800
Received: from EX-US01.tencent.com ([fe80::dd89:24b4:594b:5bbe]) by EX-US01.tencent.com ([fe80::dd89:24b4:594b:5bbe%4]) with mapi id 15.01.2106.002; Tue, 19 Jan 2021 15:57:56 +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/KMAgAFGLICABk8hAIAp/OqAgAB9+QCABIYGgIABo8oAgACNQoA=
Date: Tue, 19 Jan 2021 07:57:56 +0000
Message-ID: <A39C2CEE-6F55-49CF-9713-E66E25FD7E8C@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> <b463a0b1-aad8-8534-e33e-f2c415441b60@alum.mit.edu> <AM0PR07MB38605AA9594E6511CBD0BDCB93A80@AM0PR07MB3860.eurprd07.prod.outlook.com> <d0ccc4f1-46b8-0b0e-4981-856a1eadd5a6@alum.mit.edu> <9554D892-4C5F-4D8D-BD90-3784DB456752@tencent.com> <ccf67fd2-43fd-e531-388d-b898209cb1f6@alum.mit.edu>
In-Reply-To: <ccf67fd2-43fd-e531-388d-b898209cb1f6@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.19.161.56]
Content-Type: multipart/alternative; boundary="_000_A39C2CEE6F5549CF9713E66E25FD7E8Ctencentcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/2ji614uC1qhJONLkwfqt_89sIpg>
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, 19 Jan 2021 07:58:07 -0000

Hi Paul,



Thanks again for your feedback.

My comments below



On 1/18/21, 7:32 AM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:



    On 1/17/21 5:29 PM, rabhishek(RohitAbhishek) wrote:

    > Hi Paul, Christer,

    >

    > My understanding is the transparent attribute is same as alpha compositing which would control the linear interpolation between the foreground and the background pixels. Here’s an example wrt figure 1 in the draft.



    First, I'm concerned with you starting your reply with "my understanding

    is ...". This is your draft! The goal is to ensure that all readers come

    to the same understanding. There should be no vagueness.



Rohit: I will make sure to phrase it correctly moving forward 😃



    Another thing: Section 5 says:



            transparency-attribute =

                         "a=transparency:" transparency-tag

            transparency-tag =tranparency-value *("," tranparency-value) CRLF

            transparency-value= alpha



        Alpha describes the transparency for the foreground media stream.  It

        is identified by its transparency-tag values in the transparency-

        attribute.  It could be an integer with values between 0 and 100.

        This is an informative value.  Details of interpretion to be left

        open to the renderer, expect that a value of 0 means foreground media

        is opaque and value of 100 means that it is transparent.



     From an ABNF perspective "alpha" is undefined. The text says it *could

    be" an integer between 0 and 100, but "details of interpretation are

    open to the renderer". That negates the value of creating a standard.

    The whole point of a standard is to ensure that interoperating parties

    handle things the same way.



Rohit: The value can be between 0-1/0-10/0-100 with lowest value indicating opaque and highest value indicates that it is transparent.  Do you mean I should be specific with the values or will changing the text to " expect that lowest value means foreground media is opaque and highest value means that it is transparent" be acceptable?



    > X= Background Image

    > A, B, C= foreground image (Media C partially over B)

    > Transparency(to be applied each pixel) =alpha(A), beta (B), gamma (C)

    > Background media which shows through A= (1-alpha)X

    > Background media which shows through B and C = (1-beta)( 1-gamma)X

    > Overall composed image= gamma.C+ (1-gamma)[beta.B+ (1- beta.B)X]



    I don't know much about this technology, so perhaps this would be well

    known to implementers. But it shouldn't just be assumed. If this is then

    intended mechanism then it should be specified in the document, either

    directly or by reference to some public document.



Rohit: Will include the reference in the update



    Finally, ISTM that you don't need to treat the background document as a

    special case. The grouping mechanism can be used to identify all the

    media streams participating in this superposition mechanism, including

    the one you are considering to be the background.



    IIUC the scheme you describe defines the result of superposition based

    on the transparency values of the individual streams, so that no other

    ordering mechanism is needed. (Do I have that right?) If so, isn't the

    background just the media stream with tranparency = 100?



Rohit: The ordering mechanism will be needed. Suppose we have a background X with transparency=100, and a superimposed media A with transparency=50. A over X would mean that X would visible partially through A, however X over A would mean that A wouldn't show through X.



Best Regards,

Rohit



                Thanks,

                Paul



    > Best Regards,

    > Rohit

    >

    > On 1/14/21, 9:25 AM, "mmusic on behalf of Paul Kyzivat" <mmusic-bounces@ietf.org on behalf of pkyzivat@alum.mit.edu> wrote:

    >

    >      On 1/14/21 4:54 AM, Christer Holmberg wrote:

    >      > Hi,

    >      >

    >      >> One more thing, regarding transparency:

    >      >>

    >      >> I'm fuzzy on how this is intended to work. I would think that each superposition layer would have some parts that are fully transparent.

    >      >> (Transparent pixels.) And then the transparency attribute would apply to the parts that aren't fully transparent. But that is only a guess. I think you need to say more about how the superposition is supposed to work.

    >      >

    >      > Isn't "transparent background" information carried within the video stream (codec or container) itself?

    >

    >      That is my impression, but I don't really know. But the transparency

    >      attribute must do *something*.

    >

    >      The draft needs to explain better.

    >

    >        Thanks,

    >        Paul

    >

    >      > Regards,

    >      >

    >      > Christer

    >      >

    >      >

    >      >

    >      > On 12/14/20 11:21 AM, Paul Kyzivat 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-superimpositio

    >      >>>> n-grouping-00.txt

    >      >>>>

    >      >>>>       Status:

    >      >>>> https://datatracker.ietf.org/doc/draft-abhishek-mmusic-superimpositi

    >      >>>> on-grouping/

    >      >>>>

    >      >>>>       Htmlized:

    >      >>>> https://datatracker.ietf.org/doc/html/draft-abhishek-mmusic-superimp

    >      >>>> osition-grouping

    >      >>>>

    >      >>>>       Htmlized:

    >      >>>> https://tools.ietf.org/html/draft-abhishek-mmusic-superimposition-gr

    >      >>>> ouping-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

    >      >

    >      > _______________________________________________

    >      > 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

    >