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

[Roni Even <[e-mail]>]

Hi Colin,
I re-read RFC5888 and tried to understand what is the difference between FID and LS
I was trying to understand what is a flow and from section 8.3 

"The previous examples show that the definition of a media stream in
   [RFC2326] does not cover some scenarios.  It cannot be assumed that a
   single media instance maps into a single RTP session.  Therefore, we
   introduce the definition of a media flow:

      A media flow consists of a single media instance, e.g., an audio
      stream or a video stream as well as a single whiteboard or shared
      application group.  When using RTP, a media flow comprises one or
      more RTP sessions."

It looks to me that a media flow is a SINGLE media stream that spans over multiple RTP sessions (the term media instance is a what we call a media stream in the taxonomy). Section 8.5 (8.5.1) enhance this by saying when FID cannot be used " FID semantics are useful when the application only uses one codec at   a time"  which again describe a flow as a single media stream.

I am not sure how ANC and the video relates to each other this is what I am asking Thomas to be more clear. If the video and ANC are one stream over multiple RTP sessions FID is correct otherwise I think the LS should be used.
My reading on  the ancillary draft is that ANC and the video are what we call a single RTP stream but this is not what Thomas says.

Roni

> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: יום ג 03 אוקטובר 2017 21:51
> To: Roni Even
> Cc: Adam Roach; Thomas Edwards; The IESG; [e-mail]; draft-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-
> ancillary-10: (with DISCUSS and COMMENT)
> 
> Hi Roni,
> 
> I tend to think the “decoded at the sane time” issue is over-interpreting the
> wording of RFC 5888. The metadata and the media to “form a media flow”,
> which is the definition of FID.
> 
> Colin
> 
> 
> > On 3 Oct 2017, at 18:53, Roni Even <[e-mail]> wrote:
> >
> > Hi Colin,
> > I think that the question is if the video and anc are decoded at the same
> time. In RFC 5888 the case when DTMF is both in the audio and as DTMF
> tones (section 8.5.1 ) FID cannot be used only if audio is muted when DTMF
> tones are sent.
> > So the question is if video is muted when ANC is sent (only one decode at a
> specific time). I think that in term of time they are both part of the same
> video frame so they have the same time so I am not sure if FID can be used.
> Maybe Thomas can provide is view here if they are decodec in parallel or one
> after the other?
> > And yes they MUST have the same CNAME regardless of the grouping
> > specified Roni
> >
> >
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:[e-mail]]
> >> Sent: יום ג 03 אוקטובר 2017 19:56
> >> To: Adam Roach
> >> Cc: Thomas Edwards; The IESG; [e-mail];
> >> draft-ietf-payload- [e-mail]; [e-mail];
> >> [e-mail]
> >> Subject: Re: [payload] Adam Roach's Discuss on
> >> draft-ietf-payload-rtp-
> >> ancillary-10: (with DISCUSS and COMMENT)
> >>
> >>> On 29 Sep 2017, at 22:00, Adam Roach <[e-mail]> wrote:
> >>> On 9/26/17 8:13 PM, Thomas Edwards wrote:
> >>>> 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.
> >>>
> >>> In this case, where you have data and meta-data, it's arguably two
> >> different codecs; and, since they don't represent the same data,
> >> you're encoding with one codec or the other, based on whether you're
> >> sending video data or meta-data. From that perspective, I don't see
> >> the use of FID as being outside the spirit of what is intended.
> >>>
> >>> That said, if the WG agrees with your evaluation that FID isn't
> >>> quite the
> >> right fit, I'm happy for y'all to come up with some alternate solution...
> >>
> >> I tend to agree with Adam that FID is appropriate to group the
> >> ancillary data with its associated media stream. The metadata in the
> >> ancillary stream is conceptually part of the media stream, which matches
> the definition of FID.
> >> They MUST be sent with the same CNAME, to ensure they can be
> >> synchronised, but that doesn’t require any explicit signalling.
> >>
> >> You can use LS signalling in addition to FID if two streams, with
> >> their associated ancillary streams, need to be synchronised.
> >>
> >> --
> >> Colin Perkins
> >> https://csperkins.org/
> >>
> >>
> >>
> >
> 
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
>