Re: [MMUSIC] FW: New Version Notification for draft-abhishek-mmusic-superimposition-grouping-01.txt

[Rohit Abhishek <[e-mail]>]

Dear Paul, Christer,

Thank you again from your comments and suggestions.

On Mon, Mar 29, 2021 at 4:08 AM Christer Holmberg <christer.holmberg=
[e-mail]> wrote:

> Hi,
>
> >* I'm still unsure how transparency works. Does the transparency value
> apply to all pixels in the associated stream? Or is is also possible that
> some pixels are transparent
> >and others are opaque? (I'm thinking of closed captioning, where the
> characters themselves are opaque but their own background is opaque.) I
> would like to see some
> >discussion of the role of streams that contain some transparent pixels.
>
> I don't think it is up to us to define how transparency works, but I agree
> that it would be good with a short description and/or reference to where it
> is specified.
>

"transparency" value is a factor for increasing or decreasing the
transparency of each pixel within a stream by the same factor. Therefore,
the "transparency" attribute defined in the draft applies to each pixel in
the associated stream.

An alpha channel generally represents transparency information on a
per-pixel basis; therefore pixels in a stream may be associated with an
already existing alpha value. (although it represents transparency; it
actually signifies the opacity of a pixel)
Now, it is possible that some pixels in the associated stream maybe
transparent(alpha=0)/opaque(alpha=1)/translucent (alpha=0.5); as in the
case of closed captioning or logo. However, these are predefined values.
The "transparency" value in the draft increases/decreases that value by the
defined factor.

Let's take the closed captioning example,
Case 1: where the pixels for the characters are opaque (transparency=0) and
background is translucent (transparency=0.5). If we apply a "transparency""
value of 0.5 (scale  0-1), it would mean that we are increasing the
transparency of each pixel by 50%. Therefore, the transparency for
character pixels would now be 0.5; whereas for the background would be
0.75.
Case 2: where the pixels for the characters are opaque (transparency=0) and
background is transparent (transparency=1 (scale  0-1)). If we apply a
"transparency" value of 0.5 (scale  0-1) here, the transparency for
character pixels would be 0.5; however, the transparency of the background
would still be 1 or completely transparent.

I plan on adding the below text to the draft for clarification.
" The transparency value is used for composing the foreground with the
background media [ref:Alpha-compositing]. This value itself does not define
the transparency of each pixel, but is applied to each pixel within a frame
and defines the factor by which the transparency of each pixel within a
frame is to be increased or decreased."
(Does it help or more clarification needs to be added?)

>
> >* Are you assuming there is time synchronization among all the streams in
> the superimposition group? If so please say so. If not then you need to say
> more about how they are to be synchronized.
>
> I agree it would be good to say something about this.
>

> However, if there is no requirement for synchronization, I don't think we
> shall impose such requirement. However, if needed, we do have the lipsynch
> (LS) group attribute (RFC5888).
>

Yes it is assumed that there is time synchronization. The updated text is
"The "superimposition media stream identification" attribute is used to
identify the relationship of superimposed media streams within a session
description. In a superimposition group, the media lines MAY have different
media formats but, to be meaningful, SHOULD be visual media. It is assumed
that all the media streams are time synchronized."

>
> >* You are using both "superimposition" and "superposition". These have
> somewhat different (but fuzzy to me) distinctions. Unless you need both
> along with their distinctions I suggest you pick one and use it throughout.
>
> Agree.
>
Will change it to "superimposition". Section 5 would be updated accordingly.

>
> >* You also use the term "supim" as the grouping token. I don't think
> choosing a separate term here is beneficial. I suggest you use the same
> term (superimposition or superposition) you choose.
>
> This I don't agree with. If you look in the IANA registry, *ALL*
> registered token are short 2-6 character abbreviations.
>
> >* I can't find anything that says how the layer numbers are to be
> interpreted. Is zero the background, with higher numbered layers stacking
> on top of it? Or is zero the foreground, with higher numbered
> >layers stacked behind it. (I guess zero is the background, but am not
> certain.)
>
> Agree.
>
 Yes, zero denotes the background, with higher numbered layers stacking on
top of it.
The current text in section 5 reads
“The layering order value is an integer value between 0 to n, where the
value 0 represents the most background layer. For each k within 0..n, a
reconstructed sample of the k-th media is superimposed (while perhaps
applying an alpha transparency value) on the 0 to k-th reconstructed
samples in the same spatial position."

Is more clarity needed here? or are you referring to sec 6; which only says
"Media stream with layer order value 0 is intended for background."

>
> >* You seem to use "alpha" and "beta" in a way that implies that these
> terms have a specific meaning in the context of superimposition. But I find
> nothing in the document that makes this explicit.
> >The text of section 5 associates them with numeric values, but the ABNF
> uses them as rule names without defining them. At the very least you need
> to define them in ABNF.
>
> In addition, I don't think one should use "alpha" in ABNF to begin with,
> because people may confuse it with ALPHA.
>
> Regards,
>
> Christer
>
>
>
> * In your reply to Christer you mentioned RFC7195 as having a syntax style
> that you like. If so, you certainly can copy that style. (There is no
> benefit in actually referencing RFC7195. I don't see anything in there that
> it would be meaningful to reference directly.) For instance, you might
> write your syntax as follows:
>
>       superimposition-attribute =
>          "superimposition:" super-opt *(SP super-opt)
>       super-opt = super-trans / super-layer
>       super-trans = "transparency:" super-trans-val
>       super-layer = "layer:" super-layer-val
>       super-trans-val = signed-integer ; range [-128, 127]
>       super-layer-val = signed-integer ; range [0, 255]
>
>       signed-integer =
>          <zero-based-integer defined in RFC8866>
>          / "-" <integer defined in RFC8866>
>
>       attribute = <attribute defined in RFC4566>
>       attribute =/ superimposition-attribute
>
> You can adjust as you see fit. In addition to this formal ABNF you will
> also need some normative (e.g. MUST) text for a few things:
>
Thank you! This is very helpful!


>
> - *normatively* define the ranges for super-trans-val and
>    super-layer-val. (The comment in the ABNF, while helpful,
>    isn't normative. E.g.,
>    "The value of the 'transparency' option MUST be within the range
>    [-128, 127]."
>
>    (Alternatively the ABNF could be written to accept only the
>    permitted values. But doing so requires complex and hard to
>    read ABNF.)
>
> - Normatively specify what happens when either transparency or layer
>    is specified multiple times within the same media description.
>    This can occur in more than one way. E.g.,
>
>    m=...
>    a=superimposition:transparency:0 transparency:1
>
>    m=...
>    a=superimposition:layer:0
>    a=superimposition:layer:1
>
> You have options here: you can forbid specifying either of these more than
> once (via MUST NOT), or you can define what it means if it happens.
> (E.g., use the last specified value.)
>

Based on the about comments; Updated text for Section 5

"The transparency for the media stream is identified by its super-trans-val
values in the super-trans attribute. The value MUST be an ASCII
representation of an 8 bit signed integer with values between "-128" and
"127", and linear weighting between the two extremes. A value of -128 means
media stream is opaque and the highest value of 127 means it is
transparent. The layering order value for the media stream is identified by
super-layer-val. It MUST be an integer value between 0 to n, where the
value 0 represents the most background layer. For each k within 0..n, a
reconstructed sample of the k-th media is superimposed (while perhaps
applying an alpha transparency value) on the 0 to k-th reconstructed
samples in the same spatial position. Each "m" line in a session MUST NOT
contain more than one instance of each super-trans and super-layer
attributes."


Best Regards,
Rohit

>
>         Thanks,
>         Paul
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>