Re: [MMUSIC] My review comments of draft-pthatcher-mmusic-rid-02

[Bo Burman <[e-mail]>]

I think I might be able to clarify that.

It comes from the fact that hand-held cameras, like in mobile terminals, typically do not change the orientation of the picture input to the video encoder on the sender side when the device is tilted. Therefore, it will send a bitstream with syntax elements indicating (for example) 640 (width)  times 480 (height) regardless of which direction is "up".

As a counter-example, you could imagine that the video encoder would change this to (same example) 480 (width) times 640 (height) when the sender side device and camera orientation changes, but this is typically not done.

Instead, an RTP Header Extension element is added to the encoded RTP stream with information about how the decoded pictures should be rotated after decoding but before display to present the correct side "up". A rotation of 0 degrees is "no rotation", meaning that the actually displayed resolution is the same as was indicated by the syntax in the encoded video bitstream.

See section 6.2.3.3 in 3GPP TS 26.114 (http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-d10.zip) for details.

Some more information might be needed in the draft, but I don't think all of the above is needed there.

Cheers,
Bo

> -----Original Message-----
> From: Roni Even [mailto:[e-mail]]
> Sent: den 4 november 2015 09:40
> To: Magnus Westerlund; 'mmusic (E-mail)'; [e-mail]
> Subject: RE: [MMUSIC] My review comments of draft-pthatcher-mmusic-rid-02
> 
> Hi Magnus,
> I agree that it is important to specify what the constrains represent, is it of the encoded stream or the actual resolution
> requested or sent .
> If it is the encoded constrains based on your proposed change it is not clear what  the following text means ." In the case
> that  stream orientation signaling is used to modify the intended  display orientation, this
> attribute refers to the width of the   stream when a rotation of zero
> degrees is encoded.
> Roni
> 
> 
> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of Magnus Westerlund
> Sent: Tuesday, November 03, 2015 4:33 AM
> To: mmusic (E-mail); [e-mail]
> Subject: Re: [MMUSIC] My review comments of draft-pthatcher-mmusic-rid-02
> 
> Hi,
> 
> I have addition to my review comments.
> 
> For the rid-attributes that has to do with constraints on the resolution. I think they should be more explicit that this
> constraint applies to the encoded stream that the sender produces.
> 
> In most cases it should be as simple to add "of the encoded stream" with a reference to:
> https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/
> 
> Like this.
> 
>    o  max-width, for spatial resolution in pixels of the encoded
>        stream.  In the case that
>        stream orientation signaling is used to modify the intended
>        display orientation, this attribute refers to the width of the
>        stream when a rotation of zero degrees is encoded.
> 
> Cheers
> 
> Magnus Westerlund
> 
> Den 2015-10-31 kl. 18:06, skrev Magnus Westerlund:
> > Hi,
> >
> > On my flight to Yokohama I reviewed the draft and have the following
> > comments. Note, I haven't checked this against the other postings on
> > open issues. Note, this might looks like a lot, but most issues are
> > quite small and questions of clarity of text.
> >
> >
> > 1. Abstract:
> >
> > "a) effectively identify the Source RTP Streams within a RTP Session,"
> >
> > I wonder over this text. What "identity" is referenced? Media source
> > is identified otherwise, e.g. MID.
> >
> > 2. Section 1:
> >
> >     Recent advances in standards such as RTCWEB and NETVC have given rise
> >     to rich multimedia applications requiring support for multiple RTP
> >     Streams with in a RTP session
> >
> > I fail to see how NETVC is relevant in this?
> >
> > 3. Section 1:
> >
> >     o  The restricted RTP PT space in specifying the various payload
> >        configurations,
> >
> > It is not clear which restriction that is mentioned here.
> >
> > 4. Section 3 (maybe):
> >
> > The document needs better definitions, especially I am missing a
> > proper definition and name for the PT + RID constraints. What I see
> > Section uses "RTP Payload Configuration". I think that word is a bit
> > unclear, as that can equally mean what is configured to apply the PT.
> >
> > 5. Section 4.
> >
> >     1.  RTP PT Space Exhaustion: [RFC3550] defines payload type (PT) that
> >         identifies the format of the RTP payload and determine its
> >         interpretation by the application.  [RFC3550] assigns 7 bits for
> >         the PT in the RTP header.  However, the assignment of static
> >         mapping of payload codes to payload formats and multiplexing of
> >         RTP with other protocols (such as RTCP) could result in limited
> >         number of payload type numbers available for the application
> >         usage.  In scenarios where the number of possible RTP payload
> >         configurations exceed the available PT space within a RTP
> >         Session, there is need a way to represent the additional
> >         constraints on payload configurations and to effectively map a
> >         Source RTP Stream to its corresponding constraints.
> >
> > I would really prefer this was reformulated to clarify that that the
> > PT exhaustion is primarily a result of overloading usage of various
> > types rather than the basic encoding and packetization parameters
> identification.
> >
> > 6. Section 4:
> >
> > Note that the bullets both are labelled as 1.
> >
> > 7. Section 4:
> >
> >          Recently, there is a
> >         rising trend with real-time multimedia applications supporting
> >         multiple sources per endpoint with various temporal resolutions
> >         (Scalable Video Codec) and spatial resolutions (Simulcast) per
> >         source.
> >
> > This sentence is way to overloaded and should be split into the
> > different trends.
> >
> > 8. Section 5.
> >
> >     Though the 'rid-level' attributes specified by the 'rid' property
> >     follow the syntax similar to session-level and media-level
> >     attributes, they are defined independently.
> >
> > This appear to not be working as the delimitation of rid-level
> > attributes are not made clear. The formal syntax says that the only
> > separator is ";", but that is not explained here. Clarification of how
> > this is expected to work is needed.
> >
> > 9. Section 7.
> >
> > With current lack of wording it appears that it is allowed to use a
> > specific rid-identifier, e.g. "a" for different sets of constraints in
> > various different m= sections. I wonder if that really should be
> > allowed? Might be simpler to restrict the re-use of labels across
> > multiple m= sections only in cases where there RID attributes are the
> same.
> >
> > 10. Section 7.1-
> >
> > I think the handling of the "pt" value is unclear. To my understanding
> > you may? exclude it and have it apply to all PT formats in m= line.
> > However that is not well formulated. It is unclear that if you may
> > included all PTs in the pt= parameter. This applies also to the
> > following O/A steps also.
> >
> > 11. Section 7.1:
> >
> > Bullet 3:
> >
> > (usually corresponding to RTP payload types)
> >
> > To my understanding RID is currently restricted to RTP, thus, it is
> > not "usually corresponding".
> >
> > 12. Section 7.2:
> >
> >     2.  If the "a=rid" line contains a "pt=" parameter, the list of
> >         payload types is verified against the list of valid payload types
> >         for the media section (that is, those listed on the "m=" line).
> >         If there is no match for the Payload Type listed in the "a=rid"
> >         line, then remove the "a=rid" line.
> >
> > I wonder if removing the whole line is the right approach here. If one
> > would remove the attributes the answerer don't understand then one
> > would get more information back to the offerer. The offerer could
> > identify the attributes not supported. Yes, the offerer may have to
> > not use the rid, but in some cases it could do that despite missing
> > some
> constraints.
> > What functionality do we really want here?
> >
> > 13. Section 7.3:
> >
> >     Note: in the case that the answerer uses different PT values to
> >     represent a codec than the offerer did, the "a=rid" values in the
> >     answer use the PT values that were sent in the offer.
> >
> > I think this gets confusing as the answering SDP will not correctly
> > describe the streams going to the answerer. If I remember correctly,
> > the answer may actually add new PTs and they must be possible to
> > include in the RID line. Thus, I wonder if this rule can work. Yes, I
> > agree having to map them is difficult, and they are actually
> directionality dependent.
> >
> > 14. Section 8.
> >
> > I wonder if one can work the length consideration into the general
> > SDES item description.
> >
> > 15. Section 8.
> > Although draft-ietf-avtext-sdes-hdr-ext does discuss information
> > change as a reason for needing to send the data. However, I think the
> > RID information for a particular SSRC is a bit of specific case. Thus,
> > I wonder if one should expand a bit on the actual SDES item and its needs.
> >
> > 16. Section 10.
> >
> >     int-param-val     = 1*DIGIT
> >
> > Should this really be totally unlimited in length. I can understand
> > that one needs to support long values, but having no limitation, is
> > that safe and reasonable to parse?
> >
> > 17. Section 10.
> >
> >     param-val         = *( %x20-58 / %x60-7E )
> >                         ; Any printable character except semicolon
> >
> > Lets get back to escaping. I know this has been raised. But, I think
> > what is currently specified is to limiting. The first part is the
> > 7-bit ascii, that appears to limiting considering SDP's UTF-8 support.
> >
> > The next issue is really about delimiting parameters in a good way,
> > that also can support adaptation of parameters without having to
> > redefine the completely in the future.
> >
> > Cheers
> >
> > Magnus Westerlund
> >
> > ----------------------------------------------------------------------
> > Services, Media and Network features, Ericsson Research EAB/TXM
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  [phone]
> > Färögatan 6                 | Mobile [phone]
> > SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> > ----------------------------------------------------------------------
> >
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> 
> 
> --
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic