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

[Paul Kyzivat <[e-mail]>]

rabhishek,

I'm including mmusic in this reply. (Private discussions about drafts 
are not ideal.)

This includes my comments on the current -01 version in general.

On 2/2/21 12:37 AM, rabhishek(RohitAbhishek) wrote:
> Dear Christer, Paul,
> 
> Thanks again for reviewing the earlier version of the draft and providing the comments and key ideas.
> The 01 version has now been uploaded and is available for review.
> 
> Based on the comments and concerns received, we have made the following updates to the draft.
> 
> -The group name has been changed from “S” to “supim”
> -The “supim” now groups the background media along with the foreground media
> -A new attribute  “superimposition” has been added, which specifies the transparency and the layer order, with layer value 0 meaning the media stream is background media.
> -Background media (layer value 0) has been added to the example in section 6
> -In section 1, reference to CLUE has been added.
> -In section 3, the syntax for ‘mid’ attribute has been removed, and reference to RFC5888 has been included instead
> - In section 3, the text now reads,  “  An application that chooses to implement the extension….”.  Also added “ For non-supporting devices, these media streams are treated as independent media streams”
> - In section 5, only ABNF for addition to syntax has  been specified as instructed
> - In Sec 5, Transparency value has been added.  Beta value for layering order has been added which is an inter value between 0 to n, where 0 represents the most background layer.
> 
> You can find diff from the last version at the link below.
> https://www.ietf.org/rfcdiff?url2=draft-abhishek-mmusic-superimposition-grouping-01
> 
> Best Regards,
> Rohit

Here are some general issues:

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

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

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

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

* 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.)

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

- *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.)

	Thanks,
	Paul