Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT)

[Colin Perkins <[e-mail]>]

No, I think it’s orthogonal to grouping. If the CNAME was sufficient, then we wouldn’t need the LS grouping method.

Colin



> On 3 Oct 2017, at 19:00, Roni Even <[e-mail]> wrote:
> 
> Hi Colin,
> So maybe the right direction is that there is no need for grouping at all in this case and  just use the same CNAME in RTCP.
> Roni
> 
>> -----Original Message-----
>> From: Colin Perkins [mailto:[e-mail]]
>> Sent: יום ג 03 אוקטובר 2017 19:59
>> To: Roni Even
>> Cc: Thomas Edwards; Adam Roach; [e-mail]; draft-ietf-
>> [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-
>> ancillary-10: (with DISCUSS and COMMENT)
>> 
>> Roni,
>> 
>> The requirement for RTP, in general, is that streams that are to be
>> synchronised MUST have the same RTCP CNAME. It might be appropriate to
>> remind readers of that, but it’s independent on the grouping framework.
>> 
>> How that CNAME is chosen doesn’t matter for the purposes of
>> synchronisation, provided the SSRCs that are to be synchronised use the
>> same CNAME. The suggestions in RFC 7022 are appropriate, but there’s no
>> reason to mandate them, or require a particular one of those suggestions be
>> used.
>> 
>> Colin
>> 
>> 
>> 
>>> On 1 Oct 2017, at 12:25, Roni Even <[e-mail]> wrote:
>>> 
>>> Hi Thomas,
>>> I think that you should also have in the grouping section a
>>> recommendation to use the same persistent CNAME (maybe short term?)
>>> for the ANC and video stream see RFC 7022 this is required in RTCP if
>>> these RTP streams need to be synchronized (RFC3550) Roni
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Thomas Edwards [mailto:[e-mail]]
>>>> Sent: יום ד 27 ספטמבר 2017 18:47
>>>> To: Roni Even; Adam Roach; The IESG
>>>> Cc: [e-mail];
>>>> [e-mail];
>>>> [e-mail]; [e-mail]
>>>> Subject: Re: Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10:
>>>> (with DISCUSS and COMMENT)
>>>> 
>>>> Roni, thanks for the feedback on LS!
>>>> 
>>>> I’m still not sure if it is appropriate to include the hierarchical
>>>> grouping SDP example in draft-ietf-payload-rtp-ancillary.  I suspect it could
>> be confusing.
>>>> 
>>>> However, I will note that the Alliance for IP Media Solutions
>>>> (http://aimsalliance.org) Technical Committee is considering work on
>>>> documenting different SDP groupings for live television production
>>>> scenarios, so it is possible that a future I-D will be submitted that
>>>> could include a range of SDP applications in this area, perhaps
>>>> including documentation of Adam Roach’s scenario.
>>>> 
>>>> I can go ahead and upload a draft-ietf-payload-rtp-ancillary-11 based
>>>> on the IESG feedback.
>>>> 
>>>> -Thomas
>>>> 
>>>> --
>>>> Thomas Edwards
>>>> FOX Networks Engineering & Operations VP Engineering & Development
>>>> [e-mail]
>>>> [phone]
>>>> 10201 W Pico Blvd
>>>> Los Angeles, CA 90035
>>>> 
>>>> 
>>>> On 9/27/17, 4:07 AM, "Roni Even" <[e-mail]> wrote:
>>>> 
>>>>   Hi,
>>>> 
>>>>   I agree that LS is better fit for ANC
>>>> 
>>>> 
>>>> 
>>>>   As for Adam's example it is allowed by RFC5888 to specify
>>>> 
>>>>           a=group:LS V1 V2 M1 M2
>>>> 
>>>>           a=group:LS V1 M1
>>>> 
>>>>           a=group:LS V2  M2
>>>> 
>>>>   this is similar to RFC5956  which replaced RFC4756
>>>> 
>>>> 
>>>> 
>>>>   this is not a clean way but  is allowed otherwise there is a need
>>>> to specify some SDP attribute for specifying dependencies.
>>>> 
>>>> 
>>>> 
>>>>   Roni Even
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>> 
>>>>> From: Thomas Edwards [mailto:[e-mail]]
>>>> 
>>>>> Sent: יום ד 27 ספטמבר 2017 04:13
>>>> 
>>>>> To: Adam Roach; The IESG
>>>> 
>>>>> Cc: [e-mail];
>>>>> [e-mail];
>>>> 
>>>>> [e-mail]; [e-mail]
>>>> 
>>>>> Subject: Re: Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10:
>>>> 
>>>>> (with DISCUSS and COMMENT)
>>>> 
>>>>> 
>>>> 
>>>>> Regarding draft-ietf-payload-rtp-ancillary-10, on further thought I
>>>>> believe
>>>> 
>>>>> that FID grouping is NOT appropriate for Section 4.1 “Grouping ANC
>>>> Streams
>>>> 
>>>>> with other Media Streams”.
>>>> 
>>>>> 
>>>> 
>>>>> RFC 5888 Section 8.4. (“FID Semantics”) states:
>>>> 
>>>>> 
>>>> 
>>>>>      “It is assumed that the application uses only one codec at a
>>>>> time to
>>>> 
>>>>> encode the media produced.  This codec MAY change dynamically during
>>>> the
>>>> 
>>>>> session, but at any particular moment, only one codec is in use.”
>>>> 
>>>>> 
>>>> 
>>>>> RFC 5888 Section 8.5.1 states:
>>>> 
>>>>> 
>>>> 
>>>>> 	“FID semantics are useful when the application only uses one codec
>>>> 
>>>>> at a time.  An application that encodes the same media using
>>>>> different
>>>> 
>>>>> codecs simultaneously MUST NOT use FID to group those media lines.”
>>>> 
>>>>> 
>>>> 
>>>>> When we have one video stream and one ancillary data stream, senders
>>>> are
>>>> 
>>>>> not switching between codecs.  FID really sounds to me like a
>>>>> situation
>>>> where
>>>> 
>>>>> you have one media stream, but senders could send that stream one of
>>>> 
>>>>> multiple codecs, but not at the same time.
>>>> 
>>>>> 
>>>> 
>>>>> Compare with RFC 5888 Section 7:
>>>> 
>>>>> 
>>>> 
>>>>> 	“Note that LS semantics apply not only to a video stream that has
>>>>> to
>>>> 
>>>>> be synchronized with an audio stream; the playout of two streams of
>>>>> the
>>>> 
>>>>> same type can be synchronized as well.”
>>>> 
>>>>> 
>>>> 
>>>>> Synchronized presentation to the user of an audio, video, and of
>>>>> course
>>>> 
>>>>> ancillary data flow is generally what we need for production
>>>>> television
>>>> 
>>>>> workflows.
>>>> 
>>>>> 
>>>> 
>>>>> draft-ietf-payload-rtp-ancillary-10 Section 4.1 has the example:
>>>> 
>>>>> 
>>>> 
>>>>>       v=0
>>>> 
>>>>>       o=Al 123456 11 IN IP4
>>>> https://urldefense.proofpoint.com/v2/url?u=http-
>>>> 
>> 3A__host.example.com&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx
>>>> 6zvFcGEsbfiY9-
>>>> 
>> EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=mmtyLXtya
>>>> 
>> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=UuOwClXoGCvGP2qksiV3h85H
>>>> NgQRo_Z7b0HgU2qVwzQ&e=
>>>> 
>>>>>       s=Professional Networked Media Test
>>>> 
>>>>>       i=A test of synchronized video and ANC data
>>>> 
>>>>>       t=0 0
>>>> 
>>>>>       a=group:LS V1 M1
>>>> 
>>>>>       m=video 50000 RTP/AVP 96
>>>> 
>>>>>       c=IN IP4 https://urldefense.proofpoint.com/v2/url?u=http-
>>>> 
>> 3A__233.252.0.1_255&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zv
>>>> FcGEsbfiY9-
>>>> 
>> EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=mmtyLXtya
>>>> 
>> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=mDjccdFR8MWnfQcP_xiMhb-
>>>> bh-Wef_2tKhRDyRilYUM&e=
>>>> 
>>>>>       a=rtpmap:96 raw/90000
>>>> 
>>>>>       a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720;
>>>>> depth=10
>>>> 
>>>>>       a=mid:V1
>>>> 
>>>>>       m=video 50010 RTP/AVP 97
>>>> 
>>>>>       c=IN IP4 https://urldefense.proofpoint.com/v2/url?u=http-
>>>> 
>> 3A__233.252.0.2_255&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zv
>>>> FcGEsbfiY9-
>>>> 
>> EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=mmtyLXtya
>>>> 
>> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=7e66ewQVAuL1YUq2FzASyEJp
>>>> qw7Tc5p8fO8lZbZ4tUo&e=
>>>> 
>>>>>       a=rtpmap:97 smpte291/90000
>>>> 
>>>>>       a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}
>>>> 
>>>>>       a=mid:M1
>>>> 
>>>>> 
>>>> 
>>>>> As some have pointed out, RTP timestamps and RTCP provide inherent
>>>> 
>>>>> synchronization between “m” lines, but of course as RFC 5888 Section
>>>>> 1
>>>> says
>>>> 
>>>>> without grouping: “When a session description contains more than one
>>>> "m"
>>>> 
>>>>> line, SDP does not provide any means to express a particular
>>>>> relationship
>>>> 
>>>>> between two or more of them.”  “LS” grouping makes it pretty clear
>>>>> that
>>>> 
>>>>> these streams are intended for synchronized presentation.
>>>> 
>>>>> 
>>>> 
>>>>> An alternative to “LS” grouping is to drop all grouping in the
>>>>> example, and
>>>> be
>>>> 
>>>>> unclear about what these “m” lines are doing together in the same file:
>>>> 
>>>>> 
>>>> 
>>>>>       v=0
>>>> 
>>>>>       o=Al 123456 11 IN IP4
>>>> https://urldefense.proofpoint.com/v2/url?u=http-
>>>> 
>> 3A__host.example.com&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx
>>>> 6zvFcGEsbfiY9-
>>>> 
>> EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=mmtyLXtya
>>>> 
>> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=UuOwClXoGCvGP2qksiV3h85H
>>>> NgQRo_Z7b0HgU2qVwzQ&e=
>>>> 
>>>>>       s=Professional Networked Media Test
>>>> 
>>>>>       i=A test of synchronized video and ANC data
>>>> 
>>>>>       t=0 0
>>>> 
>>>>>       m=video 50000 RTP/AVP 96
>>>> 
>>>>>       c=IN IP4 https://urldefense.proofpoint.com/v2/url?u=http-
>>>> 
>> 3A__233.252.0.1_255&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zv
>>>> FcGEsbfiY9-
>>>> 
>> EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=mmtyLXtya
>>>> 
>> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=mDjccdFR8MWnfQcP_xiMhb-
>>>> bh-Wef_2tKhRDyRilYUM&e=
>>>> 
>>>>>       a=rtpmap:96 raw/90000
>>>> 
>>>>>       a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720;
>>>>> depth=10
>>>> 
>>>>>       m=video 50010 RTP/AVP 97
>>>> 
>>>>>       c=IN IP4 https://urldefense.proofpoint.com/v2/url?u=http-
>>>> 
>> 3A__233.252.0.2_255&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zv
>>>> FcGEsbfiY9-
>>>> 
>> EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=mmtyLXtya
>>>> 
>> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=7e66ewQVAuL1YUq2FzASyEJp
>>>> qw7Tc5p8fO8lZbZ4tUo&e=
>>>> 
>>>>>       a=rtpmap:97 smpte291/90000
>>>> 
>>>>>       a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}
>>>> 
>>>>> 
>>>> 
>>>>> But I’m still more comfortable with keeping the “LS” grouping in the
>>>> example
>>>> 
>>>>> unless there are objections.
>>>> 
>>>>> 
>>>> 
>>>>> This brings us to the main point of Adam Roach’s DISCUSS item, how
>>>>> do
>>>> you
>>>> 
>>>>> provide multi-level hierarchical grouping in SDP.  Imagine a group
>>>>> of (a
>>>> group
>>>> 
>>>>> of video and ancillary data) and (a group of video and ancillary data).
>>>> There
>>>> 
>>>>> actually is a case of this in production television, the multiviewer
>>>>> (e.g. see
>>>> 
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-
>>>> 
>> 3A__www.blackmagicdesign.com_products_multiview&d=DwIGaQ&c=uw6T
>>>> Lu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-
>>>> 
>> EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=mmtyLXtya
>>>> 
>> WHEg3JYcq3xSVLXzRqkIVgWAJDgqyIgreU&s=IdKozSZWbohK0Fg_CvZcmeNO
>>>> 6JxjGZvwknrCRLaQVX8&e=).
>>>> 
>>>>> 
>>>> 
>>>>> Unfortunately, I really can’t find any SDP mechanism to describe
>>>>> multi-
>>>> level
>>>> 
>>>>> hierarchy.  RFC 4796 “The Session Description Protocol (SDP) Content
>>>> 
>>>>> Attribute” is about the best I can find, where synchronized
>>>>> multimedia
>>>> (such
>>>> 
>>>>> as “slides”, “speaker”, “main”, etc.) is presented.  But this is a
>>>>> very limited
>>>> set
>>>> 
>>>>> of values.  RFC 5583 “Signaling Media Decoding Dependency in the
>>>> Session
>>>> 
>>>>> Description Protocol (SDP)” has various dependencies of streams, but
>>>> this is
>>>> 
>>>>> for layered or multiple descriptive media coding.  Neither of these
>>>>> seems
>>>> 
>>>>> appropriate.
>>>> 
>>>>> 
>>>> 
>>>>> Perhaps this issue needs to be brought up in Multiparty Multimedia
>>>> Session
>>>> 
>>>>> Control (mmusic) WG, but I’m not sure that it is wise to hold up the
>>>>> ANC
>>>> RTP
>>>> 
>>>>> Payload over this.
>>>> 
>>>>> 
>>>> 
>>>>> Thanks everyone!
>>>> 
>>>>> 
>>>> 
>>>>> -Thomas
>>>> 
>>>>> 
>>>> 
>>>>> --
>>>> 
>>>>> Thomas Edwards
>>>> 
>>>>> FOX Networks Engineering & Operations
>>>> 
>>>>> VP Engineering & Development
>>>> 
>>>>> [e-mail]
>>>> 
>>>>> [phone]
>>>> 
>>>>> 10201 W Pico Blvd
>>>> 
>>>>> Los Angeles, CA 90035
>>>> 
>>>>> 
>>>> 
>>>>> 
>>>> 
>>>>> 
>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> payload mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/payload
>> 
>> 
>> 
>> --
>> Colin Perkins
>> https://csperkins.org/
>> 
>> 
>> 
> 



-- 
Colin Perkins
https://csperkins.org/