Subject: Re: [AVTCORE] [External] Re: Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

From: "Hannuksela, Miska (Nokia - FI/Tampere)" <[email-masked]>
Date: Wed, 1 Sep 2021 10:45:45 +0000

Hi Ye-Kui,

Thanks for suggesting a well-justified and constructive way forward regarding item 8. Having a separate I-D describing the usage of the SEI manifest SEI message and the SEI prefix indication SEI message in SDP offer/answer in a way that suits AVC, HEVC, and VVC sounds good to me.

If it is agreed to go ahead with such separate I-D, I think the following items would still be good in VVC RTP payload so that the new I-D can be seamlessly plugged in:

  1.  Define recv-sei in a generic way, something like:

This parameter MAY be used to indicate the SEI messages a receiver supports. The value of the parameter is a comma-separated (‘,’) list of base64 [RFC4648] representations of SEI NAL units.

  1.  Include sprop-sei and recv-sei in Table 1 to enable offer-answer negotiation on properties that are signaled with SEI messages.
  2.  The semantics of sprop-sei are assuming that it is used only for declarative purposes. Specifically:

When present, a decoder can rely on the bitstream characteristics that are described in the SEI messages [in sprop-sei] …

I’d propose rephrasing as:

When an SEI message is present in the sprop-sei value of a declarative session description or indicated both in the sprop-sei value and the recv-sei in SDP offer/answer, a decoder can rely on the bitstream characteristics that are described in the SEI message …
BR,
Miska

From: Ye-Kui Wang <[email-masked]>
Sent: Tuesday, August 31, 2021 9:13 PM
To: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]>; 'Sanchez de la Fuente, Yago' <[email-masked]>; 'Stephan Wenger' <[email-masked]>
Cc: 'IETF AVTCore WG' <[email-masked]>; 'shuaiizhao(Shuai Zhao)' <[email-masked]>
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Miska, Yago, Stephan,

On item 8, indeed what Miska you suggested is aligned with the purpose of the SEI manifest SEI message and the SEI prefix indication SEI message. These two SEI messages were initially introduced into HEVC, and later added to AVC, and then to VVC version 2 (which is expected to be finalized in Jan. 2022).

Given that 1) an SEI message based offer/answer mechanism would be useful for almost all video coding standards, particularly AVC, HEVC, VVC and their extensions, and 2) in this mechanism the SEI manifest SEI message and the SEI prefix indication SEI message should be used for AVC, HEVC, VVC and their extensions, while VVC v2 is not yet finalized but will be soon, I think it’s probably better to leave this aspect outside the VVC RTP payload format, but work towards a separate I-D/RFC that would work for all video codecs, and for AVC, HEVC, VVC and their extensions, the design is based on the SEI manifest SEI message and the SEI prefix indication SEI message.

BR, YK

From: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 30, 2021 11:38
To: Sanchez de la Fuente, Yago <[email-masked]<mailto:[email-masked]>>; Ye-Kui Wang <[email-masked]<mailto:[email-masked]>>; Stephan Wenger <[email-masked]<mailto:[email-masked]>>
Cc: IETF AVTCore WG <[email-masked]<mailto:[email-masked]>>; shuaiizhao(Shuai Zhao) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Stephan, Ye-Kui, Yago,

Thanks for your responses. Below I am continuing the discussion on items that have not been concluded yet.

2) Section 7.1, profile-id semantics

         A profile_tier_level( ) syntax structure may be contained in an
         SPS, VPS, or DCI NAL units as specified in [VVC].  One of the
         following three cases applies to the container NAL unit of the
         profile_tier_level( ) syntax structure containing those PTL
         syntax elements used to derive the values of profile-id, tier-
         flag, level-id, sub-profile-id, or interop-constraints:
         ...
         3) The container NAL unit is a DCI NAL unit and the
         profile_tier_level( ) syntax structures in all DCI NAL units in
         the bitstream has the same values respectively for those PTL
         syntax elements.

  *   The first sentence above might give a wrong impression, since VPS and DCI may contain multiple PTL syntax structures. The sentence could be rephrased as follows: “As specified in [VVC], a profile_tier_level( ) syntax structure may be contained in an SPS NAL unit, and one or more profile_tier_level( ) syntax structures may be contained in a VPS NAL unit and in a DCI NAL unit.”

It's of course correct that any of the parameter sets mentioned can include more than one PTL structure, and we will adjust the text accordingly.
I don’t recall why multiple PTLs were allowed, but I don’t think it’s critical for an RTP-based system, where real-time encoders are the norm and splicing the exception.  Perhaps the easiest way to deal with problems arising from potentially multiple PTL structures (as you outline below), is to discourage those bitstreams.  Something like “VVC bitstreams transported over RTP using the technologies of this memo SHOULD contain only a single PTL structure in the DCI, VPS, and SPS.  The VVC syntax is more flexible, in allowing multiple PTL structures, but some of the mechanisms described herein would show undefined behavior.  If a system were to employ multiple PTL structures contrary to above “SHOULD”, the encoder(s) need to ensure that the mechanisms of this payload format, which are designed for only a single PTL structure, continue to work, for example by populating the multiple PTL structures with non-contradictory information.”

[YS] I think that Stephan’s suggestion here is good while I think that it only is needed for DCI. We might have several PTLs in VPS for different OLSs and that should be fine.

[MH] I agree with Yago that discouraging the use of multiple PTLs only concerns DCI NAL units.

  *   I am a bit uncertain how to interpret the phrasing “the PTL syntax structures in all DCI NAL units in the bitstream has the same values respectively for those PTL syntax structures”.

     *   Let’s take an example: there are two DCI NAL units, dciA and dciB, in the bitstream, and both of them contain two PTL structures, i.e. dciA contains ptlA1 and ptlA2 structures (in this order) and dciB contains ptlB1 and ptlB2 structures (in this order).
     *   Does the phrasing mandate ptlA1 to be the same as ptlB1, and ptlA2 to be the same as ptlB2? If so, then why is the phrasing needed at all, since the VVC standard requires all DCI NAL units in a bitstream to have the same content.
     *   Or does the phrasing mandate ptlA1 to be the same as ptlA2, and ptlB1 to be the same as ptlB2? This interpretation would not be meaningful technically, since why would an encoder include multiple PTL structures in a DCI NAL unit, if they the same values.

I think this would be solved through the above limitation.

  *   It seems that case 3 (DCI) would not work if a DCI NAL unit contains more than one PTL syntax structure. If there were multiple PTL structures in a DCI NAL unit, how would it be determined which one of them is used to derive profile-id, tier- flag, level-id, sub-profile-id, and interop-constraints? Would case 3 need to be limited to apply only if DCI NAL unit(s) contain only one PTL structure?

Yes, to the second question, and again, the problem would be solved through above limitation.

[YS] I think this is ok, but I am unsure what would we say when there is more than on PTL. What would we exactly mean with “for example by populating the multiple PTL structures with non-contradictory information”? Would it  mean that all PTLs are the same? In that case we are good. But if the meaning of non-contradictory PTLs is more relaxed, we might need to explain here a bit more. Let’s for instance take as an example two PTLs in a DCI with each indicating a different sub-profile. I would understand non-contradictory information that one of these profiles needs to be a subset of the other and not simply “disjoint” profiles. Then we would need to say that the sub-profile in the SDP needs to be the one that includes the other sub-profile. Unless we completely disallow different PTLs in a DCI, in which case the current text is ok since both sub-profiles would be exactly the same. If the later, we should clearly indicate that two PTLs in DCI are not supported but the “SHOULD” above would not be enough I think. Which one should we do?

[MH] Note that this part of the I-D discusses how the sender can derive the value for profile-id from 1) SPS, 2) VPS, or 3) DCI. Using case 1 or 2 for deriving profile-id is always possible, while DCI with a single PTL can simplify the operation. I’d tend to think that allowing multiple PTLs in DCI NAL unit is still allowed but discouraged (as Stephan suggests above). If a DCI NAL unit contains multiple PTLs, the sender needs to derive the profile-id from SPS or VPS.

5) Section 7.1, recv-ols-id

         When present, the value of recv-
         ols-id must be included only when sprop-ols-id was received and
         must refer to an output layer set in the VPS that is in the
         same dependency tree as the OLS referred to by sprop-ols-id.

  *   I don’t understand why sprop-ols-id is required in the offer in order to have recv-ols-id in the answer. Could you explain?

     *   Note that if this requirement is relaxed, Section 7.2.2.2 would also need changes.

  *   In my understanding:

     *   The absence of sprop-ols-id in an offer indicates that the offerer can transmit any OLS that is included in sprop-vps. Consequently, the answerer could respond with recv-ols-id equal to any OLS ID included in sprop-vps.
     *   The presence of sprop-ols-id in an offer indicates that the offerer only has a bitstream corresponding to the OLS indicated by sprop-ols-id and can transmit only that OLS or any OLS contains either the same layers as or a subset of the layers of the OLS indicated by sprop-ols-id.

Yago, can you take this?  I vaguely recall discussions around this, but not the conclusion.

[YS] We currently have a default value for sprop-ols-id in section 7.1, which follows the same inference rule as TargetOlsIdx in 8.1.1 in [VVC], so this means to me that the absence does not necessarily indicate that any OLS included in the sprop-vps can be transmitted. At least this was not my recollection. If we wanted to do so we should remove the inference value and state this clearly.  As for why we took this design choice, I remember we had some discussion about OLS negotiation and our intention was to keep things simple. We wanted to simplify the OLS negotiation and we decided that 1) the presence of sprop-ols-id was indicating the willingness of the sender to negotiate OLSs and the absence of it meant that that flexibility was not desired and “regular” negotiation should be carried out where the media format is included as is in the answer or removed completely (when one or more of the parameter values are not supported); and 2) when negotiating OLSs not anyone could be selected by the answerer but only a subset of the offered one (the text regarding the dependency tree).

[MH] Thanks for the explanation. With Stephan’s definition of dependency tree (below), I am able to understand all the pieces now. I don’t have strong opinions on this issue. If design stability is preferred, the current text can be kept except that I find the inference of sprop-ols-id confusing, since the inferred value is not used for anything as far as I can see. Therefore I would propose to delete the sentence on inferring the sprop-ols-id value. Or am I missing something?

  *   The term dependency tree is not defined and hence should either be avoided in the phrasing or defined.

Does this work: “[…]must refer to an OLS in the VPS that includes no layers other than all or a subset of the layers of the OLS referred to by sprop-ols-id. “

[MH] Sounds good, thanks.

6) Section 7.1, sprop-vps

         The sprop-vps parameter MAY contain one or more than one video
         parameter set NAL unit.  However, all other video parameter
         sets contained in the sprop-vps parameter MUST be consistent
         with the first video parameter set in the sprop-vps parameter.
         A video parameter set vpsB is said to be consistent with
         another video parameter set vpsA if any decoder that conforms
         to the profile, tier, level, and constraints indicated by the
         data starting from the syntax element general_profile_space to
         the syntax element general_level_idc, inclusive, in the first
         profile_tier_level( ) syntax structure in vpsA can decode any
         bitstream that conforms to the profile, tier, level, and
         constraints indicated by the data starting from the syntax
         element general_profile_space to the syntax element
         general_level_idc, inclusive, in the first profile_tier_level(
         ) syntax structure in vpsB.

  *   I don’t understand what makes the first PTL structure in a VPS special. Could you explain? Perhaps adding an informative NOTE in the text would help readers to understand this design choice.

Point 2 above should take care of this

[YS] This is a carry over from the HEVC payload format which only applied to the single layer-case and therefore the first PTL structure was mentioned there. We have more than on PTL in layered bitstream for VPSs but probably we need to do as suggested below and be stricter on all PTLs in a VPS.
[MH] Right, Yago, the already concluded point 9 should take care of this without treating the first PTL in a VPS in a special way.

8) Section 7.1, related to sprop-sei

  *   It would be helpful to enable offer-answer negotiation on properties that are signaled with SEI messages. These properties could include e.g.:

     *   Whether film grain synthesis is supported (the film grain characteristics SEI message)
     *   Whether frame packing is supported and which frame packing arrangement type to use (the frame packing arrangement SEI message)
     *   How many subpictures to use and which levels they should correspond (subpicture level information SEI message)

  *   It is suggested to allow empty or truncated SEI message payloads in sprop-sei to indicate the capability of the offerer to encode these SEI messages with any SEI message payload that starts with the bits included in sprop-sei (if any). For example, when contained in sprop-sei:

     *   The film grain characteristics SEI message with a truncated payload that only contains data up to fg_model_id indicates that the offerer is capable of producing a bitstream containing film grain of that fg_model_id value.
     *   The frame packing arrangement SEI message with an empty payload indicates that the offerer is capable of producing a bitstream with any frame packing arrangement.
     *   The subpicture level information SEI message with an empty payload indicates that the offerer is capable of encoding content with subpictures and include subpicture level information SEI message(s) into the bitstream.

  *   It is suggested to introduce an optional recv-sei parameter along the following principles:

     *   The SEI messages included in recv-sei in an answer indicate which SEI messages must be present in the bitstream from the offerer to the answerer
     *   When recv-sei is present in an answer, the SEI message types in recv-sei must be the same as or a subset of those included in the sprop-sei of the offer.
     *   When recv-sei is present in an answer, the SEI message payload for a particular SEI message type in recv-sei must start with the SEI message payload bits present (if any) in recv-sei for the same SEI message type.
     *   It is suggested to allow empty or truncated SEI message payloads in recv-sei to indicate that the answerer has the liberty to encode any values for remaining of the SEI message payload (as long as they conform to the specification where the SEI message is specified). Note that the conditions in the bullets above still apply.
     *   When an SEI message with a particular SEI message type is present in sprop-sei of an offer and is absent in recv-sei in an answer, the answerer indicates that it does not support the processing the SEI message included in sprop-sei.

I see the motivation, but implementing any of these above points would be major surgery at the current stage.  Correct me if I’m wrong, but all this could also be “bolted on” later, with no detrimental effect to interop, AFAICT.  I’m a bit reluctant.  Others?

[YS] I agree with Stephan. I understand the motivation but this is quite a big change. In particular, I was wondering whether allowing empty or truncated SEI messages is necessary or whether the SEI manifest SEI message or SEI prefix indication SEI message could be used for this purpose.

[MH] Good point, Yago, on the SEI manifest and SEI prefix indication SEI messages. I think they can indeed be used to avoid the empty or truncated SEI messages in sprop-sei and recv-sei and simplify the design. I’d think no change in sprop-sei is needed and recv-sei is simplified to the following:

     *   The SEI messages included in recv-sei in an answer indicate which SEI messages must be present in the bitstream from the offerer to the answerer
     *   When recv-sei is present in an answer, the SEI message in recv-sei must be one of the following:

        *   the SEI message must be the same as directly included in the sprop-sei of the offer;
        *   the SEI message must have a type indicated in a SEI manifest SEI message in the sprop-sei of the offer;
        *   the SEI message must have a type and start with the respective content indicated by a SEI prefix indication SEI message contained within the srop-sei.

     *   When an SEI message with a particular SEI message type is present in sprop-sei of an offer and is absent in recv-sei in an answer, the answerer indicates that it does not support the processing the SEI message included in sprop-sei.

I continue to think this would be useful for many purposes. I am opening up two of the cases I briefly mentioned above as examples:

  *   The offerer encodes stereoscopic video, with spatial or temporal frame packing. It includes SEI manifest SEI message with frame packing arrangement SEI message in sprop-sei. The answerer can deal with spatial frame packing, but temporal frame packing is not supported by its displaying process. It includes the frame packing arrangement SEI message with a spatial packing type in recv-sei of the answer.
  *   The offerer is able to encode 8K video and supports encoding of independent subpictures. It includes SEI manifest SEI message with subpicture level information SEI message in sprop-sei. The answerer can decoded 8K video only if it uses four 4K-capable processing cores, one processing core per each subpicture sequence. Thus, it includes subpicture level information SEI message indicating four subpictures, each with a level of 4K decoding capacity in the recv-sei of the answer.

10) Section 7.2.2.2, on sprop-sub-layer-id indicating the property of the highest layer only

   o  The offerer MAY include sprop-sub-layer-id which, in case of
      scalable VVC, is interpreted as the highest sub-layer of the
      highest enhancement layer in the OLS indicated by sprop-ols-id.
      The answerer MAY include recv-sub-layer-id which can be used to
      downgrade the sublayer of the highest enhancement layer.  This
      specification does not support downgrading the sub-layer of any
      layers in the OLS that are not the highest layer.
         Informative note: in other words, using this mechanism, an
         answerer can downgrade only the frame rate for the highest
         spatial/quality layer (typically corresponding to the highest
         resolution or bitrate, hence the most complex to decode), but
         not for lower spatial/quality layers.  The answerer must
         support all sublayers for lower layers in the OLS, or reject
         the offer.  That's not a big burden, as the receiver/decoder
         has the option to discard any sublayers it cannot decode,
         irrespective of what is being signalled through offer/answer.

  *   This design choice is not obvious. Note that pruning temporal sublayers from the highest layer but not from the reference layer(s) could have undesirable impacts, such as:

     *   The decoder outputs reference-layer pictures with TemporalId greater than sprop-sub-layer-id. In SNR/spatial scalability these pictures have lower quality/resolution than the pictures of the highest layer and hence cause temporally fluctuating quality/resolution.
     *   If sprop-sub-layer-id is used to input the Htid variable to the decoder as specified in Section 8.1.1 of VVC, the receiver would need to apply the sub-bitstream extraction process of VVC, C.6 to obtain a conforming bitstream.

  *   I would think that the maximum of sprop-sub-layer-id (when present) and recv-sub-layer-id (when present) MUST indicate the highest temporal sublayer to be decoded for the bitstream from the offerer to the answerer and MAY be provided as the value of Htid to the VVC decoding process as specified in Section 8.1.1 of VVC. Changes would be needed in Section 7.2.2.2 as well as in sprop-sub-layer-id and recv-sub-layer-id in Section 7.1.

Umm.  I’m lost.  Yago/Ye-Kui?

[YS] We had some internal discussion before the last update and the point that was made is that it seems that some implementations using scalability use pruning of the higher layers mainly. Having said that I agree with the issues pointed out.

So
1) Yes you would have temporally fluctuating quality/resolution
2)  sprop-sub-layer-id cannot be used to set Htid and the extraction process drops some sublayers of the highest layer, which is not how it is defined in VVC. Basically, sprop-sub-layer-id would not change the operating point and picture from non-output layers need to be output.

So if we keep this design choice we need to clarify this; that we are doing something different than how VVC defines operating points. My recollection is that this is how some products are implemented and differs from how VVC defines operating points. Stephan could you confirm that my recollection is correct?

So not sure how to proceed here. If this is how it is typically implemented, it seems reasonable to do things a bit different than how operating points are defined in VVC, but we should clearly state it. Any views on how to proceed here?

[MH] I am having hard time to understand the motivation why only the highest layer would undergo temporal sublayer pruning. And if so, would the temporally fluctuating quality/resolution be really a desirable way to display such video. Unless there are good answers, I think the I-D should be aligned with the way VVC defines operating points.

Best Regards,
Miska

---

From: "Sanchez de la Fuente, Yago" <[email-masked]>
Date: Wed, 1 Sep 2021 11:08:16 +0000

Dear Miska,

I also think that having a separate I-D for the usage of the SEI manifest SEI message and the SEI prefix indication SEI message is preferable.

I have a couple of clarification questions thought for how recv-sei would be defined in the VVC RTP payload format.

1) Would the absence of recv-sei in the answer mean none of the SEI messages in the sprop-sei are supported or all of them?

2) And how would the SDP offer/answer look like in such negotiation?

If the SEIs in the offer included in the sprop-sei are supported it is clear, the revc-sei would be the same but what about the example for stereoscopic video that you gave? Let’s say the offer includes spatial frame packing and the receiver only supports or temporal frame packing? Or would you assume that the offerer includes both frame packing SEI messages in sprop-sei, i.e. spatial and temporal frame packing?

Best regards,
Yago Sánchez

---
Department Video Communication and Applications
Group Multimedia Communications

Fraunhofer HHI - Heinrich Hertz Institute
Einsteinufer 37, 10587 Berlin, Germany
http://www.hhi.fraunhofer.de/ip/mc

Tel.: +49 30 310 02663
[email-masked]<mailto:[email-masked]>

On 1. Sep 2021, at 12:45, Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ye-Kui,

BR,
Miska

From: Ye-Kui Wang <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, August 31, 2021 9:13 PM
To: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]<mailto:[email-masked]>>; 'Sanchez de la Fuente, Yago' <[email-masked]<mailto:[email-masked]>>; 'Stephan Wenger' <[email-masked]<mailto:[email-masked]>>
Cc: 'IETF AVTCore WG' <[email-masked]<mailto:[email-masked]>>; 'shuaiizhao(Shuai Zhao)' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Miska, Yago, Stephan,

BR, YK

  *   In my understanding:

So

Best Regards,
Miska

---

From: "Hannuksela, Miska (Nokia - FI/Tampere)" <[email-masked]>
Date: Wed, 1 Sep 2021 12:02:23 +0000

Hi Yago,

Good questions, thanks! I originally thought that the absence of recv-sei would indicate that the receiver supports none of the SEI messages in sprop-sei. That said, if the receiver supports all of the SEI messages in sprop-sei, copying them all in recv-sei seems wasteful in terms of byte count. Hence, it could be specified that i) recv-sei being absent indicates that the receives supports all SEI messages in sprop-sei, and ii) recv-sei being present but having no value indicates that the receiver supports none of the SEI messages in sprop-sei.

For the stereoscopic video example, the offerer includes both frame packing SEI messages in sprop-sei, i.e. one indicating spatial frame packing and another indicating temporal frame packing. The answerer picks only one of those SEI messages (e.g. spatial frame packing) into recv-sei of the answer with exactly the same content as it had in sprop-sei.

BR,
Miska

From: Sanchez de la Fuente, Yago <[email-masked]>
Sent: Wednesday, September 1, 2021 2:08 PM
To: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]>
Cc: Ye-Kui Wang <[email-masked]>; Stephan Wenger <[email-masked]>; IETF AVTCore WG <[email-masked]>; shuaiizhao(Shuai Zhao) <[email-masked]>
Subject: Re: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Dear Miska,

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

Hi Ye-Kui,

Hi Miska, Yago, Stephan,

BR, YK

  *   In my understanding:

So

Best Regards,
Miska

---

From: "Ye-Kui Wang" <[email-masked]>
Date: Wed, 1 Sep 2021 09:10:24 -0700

Hi Miska, Yago,

I was actually meant to suggest working on a separate I-D/RFC for the entire mechanism, particularly include the recv-sei part and the associated offer/answer mechanism. 

In the separate ID/RFC, recv-sei should have a generic name and the semantics is also generic but it is instantiable for individual video codecs. For AVC/HEVC/VVC and their extensions, for example, the parameter contains an SEI NAL unit containing an SEI manifest SEI message and one or more SEI prefix indication SEI messages. And that document probably should provide some example values of the parameter(s) for different use cases, including frame packing, omnidirectional video, high dynamic range, etc. 

This way, the VVC RTP payload format plus that separate I-D/RFC would do the job for VVC; and similarly for other video codecs. Thus if it is desirable to work on that separate, generic I-D/RFC, I don’t see a need to specify recv-sei and the associated offer/answer mechanism in the VVC RTP payload format; on the contrary, I only see redundant work.

Am I missing something?

BR, YK

From: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]> 
Sent: Wednesday, September 1, 2021 5:02
To: Sanchez de la Fuente, Yago <[email-masked]>
Cc: Ye-Kui Wang <[email-masked]>; Stephan Wenger <[email-masked]>; IETF AVTCore WG <[email-masked]>; shuaiizhao(Shuai Zhao) <[email-masked]>
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Yago,

BR,

Miska

From: Sanchez de la Fuente, Yago <[email-masked] <mailto:[email-masked]> > 
Sent: Wednesday, September 1, 2021 2:08 PM
To: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked] <mailto:[email-masked]> >
Cc: Ye-Kui Wang <[email-masked] <mailto:[email-masked]> >; Stephan Wenger <[email-masked] <mailto:[email-masked]> >; IETF AVTCore WG <[email-masked] <mailto:[email-masked]> >; shuaiizhao(Shuai Zhao) <[email-masked] <mailto:[email-masked]> >
Subject: Re: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Dear Miska, 

Best regards,

Yago Sánchez

---

Tel.: +49 30 310 02663

[email-masked] <mailto:[email-masked]> 

On 1. Sep 2021, at 12:45, Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked] <mailto:[email-masked]> > wrote:

Hi Ye-Kui,

a.	Define recv-sei in a generic way, something like:

b.	Include sprop-sei and recv-sei in Table 1 to enable offer-answer negotiation on properties that are signaled with SEI messages.
c.	The semantics of sprop-sei are assuming that it is used only for declarative purposes. Specifically:

BR,

Miska

From: Ye-Kui Wang <[email-masked] <mailto:[email-masked]> > 
Sent: Tuesday, August 31, 2021 9:13 PM
To: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked] <mailto:[email-masked]> >; 'Sanchez de la Fuente, Yago' <[email-masked] <mailto:[email-masked]> >; 'Stephan Wenger' <[email-masked] <mailto:[email-masked]> >
Cc: 'IETF AVTCore WG' <[email-masked] <mailto:[email-masked]> >; 'shuaiizhao(Shuai Zhao)' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Miska, Yago, Stephan,

BR, YK

From: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked] <mailto:[email-masked]> > 
Sent: Monday, August 30, 2021 11:38
To: Sanchez de la Fuente, Yago <[email-masked] <mailto:[email-masked]> >; Ye-Kui Wang <[email-masked] <mailto:[email-masked]> >; Stephan Wenger <[email-masked] <mailto:[email-masked]> >
Cc: IETF AVTCore WG <[email-masked] <mailto:[email-masked]> >; shuaiizhao(Shuai Zhao) <[email-masked] <mailto:[email-masked]> >
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

         ...

         syntax elements.

 

 

 

*	In my understanding: 

 

 

 

So 

 

 

Best Regards,

Miska

---

From: "Sanchez de la Fuente, Yago" <[email-masked]>
Date: Thu, 2 Sep 2021 08:25:21 +0000

Hi Ye-Kui,

Good point. I was trying to understand how defining now recv-sei would work and think of how this could be used together with a separate I-D/RFC. But I see your point that it is somehow redundant and maybe what we would define in the VVC RTP payload format could end up being limiting compared to a carefully thought through solution with a larger time frame. Given that, I agree with you that the best would be to work on the entire mechanism on a separate I-D/RFC.

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

On 1. Sep 2021, at 18:10, Ye-Kui Wang <[email-masked]<mailto:[email-masked]>> wrote:

Hi Miska, Yago,

Am I missing something?

BR, YK

From: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 1, 2021 5:02
To: Sanchez de la Fuente, Yago <[email-masked]<mailto:[email-masked]>>
Cc: Ye-Kui Wang <[email-masked]<mailto:[email-masked]>>; Stephan Wenger <[email-masked]<mailto:[email-masked]>>; IETF AVTCore WG <[email-masked]<mailto:[email-masked]>>; shuaiizhao(Shuai Zhao) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Yago,

BR,
Miska

From: Sanchez de la Fuente, Yago <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 1, 2021 2:08 PM
To: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]<mailto:[email-masked]>>
Cc: Ye-Kui Wang <[email-masked]<mailto:[email-masked]>>; Stephan Wenger <[email-masked]<mailto:[email-masked]>>; IETF AVTCore WG <[email-masked]<mailto:[email-masked]>>; shuaiizhao(Shuai Zhao) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Dear Miska,

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

Hi Ye-Kui,

BR,
Miska

Hi Miska, Yago, Stephan,

BR, YK

  *   In my understanding:

So

Best Regards,
Miska

---

From: "Hannuksela, Miska (Nokia - FI/Tampere)" <[email-masked]>
Date: Thu, 2 Sep 2021 10:47:37 +0000

Hi Ye-Kui,

Thanks for clarifying – got you know.

I proposed a short definition of recv-sei in VVC RTP payload, because I thought the media type (H266) and all its optional parameters for that media type should be specified in a single specification. Then my idea was to specify the use of the SEI manifest SEI message and the SEI prefix indication SEI message with recv-sei and sprop-sei in the separate I-D/RFC. However, if it is ok from media type registration perspective to specify an optional parameter in another I-D/RFC than the media type itself, then your suggestion is acceptable to me. Hopefully someone knowledgeable of media type definitions could confirm this.

Some questions for clarification:
Do you envision to use sprop-sei in SDP offer/answer in the separate I-D/RFC?

If you envision to use sprop-sei in SDP offer/answer, would you keep sprop-sei in the VVC RTP payload? As discussed in my previous email, its semantics are declarative in nature, so some way of phrasing them to allow use in offer/answer would be good.

If you envision to define another parameter in the separate I-D/RFC to indicate offerer’s SEI capabilities, is it allowed to use sprop-sei at the same SDP as that other parameter and what would the semantics of sprop-sei then be?

BR,
Miska

From: Sanchez de la Fuente, Yago <[email-masked]>
Sent: Thursday, September 2, 2021 11:25 AM
To: Ye-Kui Wang <[email-masked]>
Cc: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]>; Stephan Wenger <[email-masked]>; IETF AVTCore WG <[email-masked]>; shuaiizhao(Shuai Zhao) <[email-masked]>
Subject: Re: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Ye-Kui,

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

Hi Miska, Yago,

Am I missing something?

BR, YK

Hi Yago,

BR,
Miska

Dear Miska,

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

Hi Ye-Kui,

Hi Miska, Yago, Stephan,

BR, YK

  *   In my understanding:

So

Best Regards,
Miska

---

From: "Ye-Kui Wang" <[email-masked]>
Date: Mon, 6 Sep 2021 19:53:23 -0700

Hi Miska,

Good questions! I think sprop-sei can be kept in the VVC RTP payload format with the current semantics. In the separate I-D/RFC a new parameter (or two, one each direction) can be defined, in a generic way, and for AVC/HEVC/VVC, the parameter(s) includes an SEI NAL unit containing an SEI manifest SEI message and zero or more SEI prefix indication SEI messages; I don’t see a need to allow this parameter to contain other types of SEI messages like allowed for sprop-sei. If both are present, then the contents need to be consistent. Does that make sense?

BR, YK

From: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]> 
Sent: Thursday, September 2, 2021 3:48
To: Sanchez de la Fuente, Yago <[email-masked]>; Ye-Kui Wang <[email-masked]>
Cc: Stephan Wenger <[email-masked]>; IETF AVTCore WG <[email-masked]>; shuaiizhao(Shuai Zhao) <[email-masked]>
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Ye-Kui,

BR,

Miska

From: Sanchez de la Fuente, Yago <[email-masked] <mailto:[email-masked]> > 
Sent: Thursday, September 2, 2021 11:25 AM
To: Ye-Kui Wang <[email-masked] <mailto:[email-masked]> >
Cc: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked] <mailto:[email-masked]> >; Stephan Wenger <[email-masked] <mailto:[email-masked]> >; IETF AVTCore WG <[email-masked] <mailto:[email-masked]> >; shuaiizhao(Shuai Zhao) <[email-masked] <mailto:[email-masked]> >
Subject: Re: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Ye-Kui, 

Best regards,

Yago Sánchez

---

Tel.: +49 30 310 02663

 

On 1. Sep 2021, at 18:10, Ye-Kui Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi Miska, Yago,

Am I missing something?

BR, YK

To: Sanchez de la Fuente, Yago <[email-masked] <mailto:[email-masked]> >

Hi Yago,

BR,

Miska

Dear Miska, 

Best regards,

Yago Sánchez

---

Tel.: +49 30 310 02663

 

Hi Ye-Kui,

BR,

Miska

Hi Miska, Yago, Stephan,

BR, YK

         ...

         syntax elements.

 

 

 

*	In my understanding: 

 

 

 

So 

 

 

Best Regards,

Miska

---

From: "Hannuksela, Miska (Nokia - FI/Tampere)" <[email-masked]>
Date: Wed, 8 Sep 2021 11:52:53 +0000

Hi Ye-Kui,

If I understand you right, you would keep sprop-sei as declarative parameter only. Its content must not be in conflict with the SEI messages that are negotiated with the mechanism in the separate I-D/RFC. This design makes sense to me.

In the separate I-D/RFC, I think it is sufficient that the parameter from sender to receiver is only for an SEI manifest SEI message and zero or more SEI prefix indication SEI messages. Consequently, taking a 360 video example, the sender could indicate that it is able to encode 360 video with either equirectangular or cubemap projection, stereoscopic video with any frame packing, and any region-wise packing arrangement.

However, I’d think the receiver wants to indicate to the sender that please use exactly the SEI messages (with their entire content) included in an SDP answer in the transmitted bitstream. E.g. please use exactly a particular 360 projection format, a particular frame packing format, and a particular region-wise packing arrangement as indicated in ERP/cubemap SEI message, frame packing arrangement SEI message, and region-wise packing SEI message included in the answer. Thus, in my opinion, in the receiver to sender direction, the parameter should allow any SEI messages without nesting them in the manifest/prefix indication SEI messages.

BR,
Miska

From: Ye-Kui Wang <[email-masked]>
Sent: Tuesday, September 7, 2021 5:53 AM
To: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]>; 'Sanchez de la Fuente, Yago' <[email-masked]>
Cc: 'Stephan Wenger' <[email-masked]>; 'IETF AVTCore WG' <[email-masked]>; 'shuaiizhao(Shuai Zhao)' <[email-masked]>
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Miska,

BR, YK

From: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, September 2, 2021 3:48
To: Sanchez de la Fuente, Yago <[email-masked]<mailto:[email-masked]>>; Ye-Kui Wang <[email-masked]<mailto:[email-masked]>>
Cc: Stephan Wenger <[email-masked]<mailto:[email-masked]>>; IETF AVTCore WG <[email-masked]<mailto:[email-masked]>>; shuaiizhao(Shuai Zhao) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Ye-Kui,

BR,
Miska

From: Sanchez de la Fuente, Yago <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, September 2, 2021 11:25 AM
To: Ye-Kui Wang <[email-masked]<mailto:[email-masked]>>
Cc: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]<mailto:[email-masked]>>; Stephan Wenger <[email-masked]<mailto:[email-masked]>>; IETF AVTCore WG <[email-masked]<mailto:[email-masked]>>; shuaiizhao(Shuai Zhao) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Ye-Kui,

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

Hi Miska, Yago,

Am I missing something?

BR, YK

Hi Yago,

BR,
Miska

Dear Miska,

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

Hi Ye-Kui,

Hi Miska, Yago, Stephan,

BR, YK

  *   In my understanding:

So

Best Regards,
Miska

---

From: "Ye-Kui Wang" <[email-masked]>
Date: Wed, 8 Sep 2021 07:24:24 -0700

Hi Miska,

The prefix indication SEI message does allow inclusion of an entire SEI message as the prefix indication in the prefix indication SEI message. Therefore that should work with the 360 video use case you described below.

BR, YK

From: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]> 
Sent: Wednesday, September 8, 2021 4:53
To: Ye-Kui Wang <[email-masked]>; 'Sanchez de la Fuente, Yago' <[email-masked]>
Cc: 'Stephan Wenger' <[email-masked]>; 'IETF AVTCore WG' <[email-masked]>; 'shuaiizhao(Shuai Zhao)' <[email-masked]>
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Ye-Kui,

BR,

Miska

From: Ye-Kui Wang <[email-masked] <mailto:[email-masked]> > 
Sent: Tuesday, September 7, 2021 5:53 AM
To: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked] <mailto:[email-masked]> >; 'Sanchez de la Fuente, Yago' <[email-masked] <mailto:[email-masked]> >
Cc: 'Stephan Wenger' <[email-masked] <mailto:[email-masked]> >; 'IETF AVTCore WG' <[email-masked] <mailto:[email-masked]> >; 'shuaiizhao(Shuai Zhao)' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Miska,

BR, YK

From: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked] <mailto:[email-masked]> > 
Sent: Thursday, September 2, 2021 3:48
To: Sanchez de la Fuente, Yago <[email-masked] <mailto:[email-masked]> >; Ye-Kui Wang <[email-masked] <mailto:[email-masked]> >
Cc: Stephan Wenger <[email-masked] <mailto:[email-masked]> >; IETF AVTCore WG <[email-masked] <mailto:[email-masked]> >; shuaiizhao(Shuai Zhao) <[email-masked] <mailto:[email-masked]> >
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Ye-Kui,

BR,

Miska

Hi Ye-Kui, 

Best regards,

Yago Sánchez

---

Tel.: +49 30 310 02663

 

Hi Miska, Yago,

Am I missing something?

BR, YK

Hi Yago,

BR,

Miska

Dear Miska, 

Best regards,

Yago Sánchez

---

Tel.: +49 30 310 02663

 

Hi Ye-Kui,

BR,

Miska

Hi Miska, Yago, Stephan,

BR, YK

To: Sanchez de la Fuente, Yago <[email-masked] <mailto:[email-masked]> >; Ye-Kui Wang <[email-masked]>; Stephan Wenger <[email-masked] <mailto:[email-masked]> >

         ...

         syntax elements.

 

 

 

*	In my understanding: 

 

 

 

So 

 

 

Best Regards,

Miska

---

From: "Hannuksela, Miska (Nokia - FI/Tampere)" <[email-masked]>
Date: Fri, 10 Sep 2021 06:19:31 +0000

Hi Ye-Kui, all,

You are right. However, such nesting is redundant when entire SEI messages are included in an answer.

This detail is anyways not relevant for the VVC RTP payload, since it only related to the separate I-D/RFC. I am copying here the items that have not been concluded yet. The discussion on items 2 and 5 are waiting for confirmations or comments by the authors and item 10 is a bigger open question on the intent of sprop-sub-layer-id.

  *   In my understanding:

So

BR,
Miska

Sent: Wednesday, September 8, 2021 5:24 PM

Hi Miska,

BR, YK

From: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 8, 2021 4:53
To: Ye-Kui Wang <[email-masked]<mailto:[email-masked]>>; 'Sanchez de la Fuente, Yago' <[email-masked]<mailto:[email-masked]>>
Cc: 'Stephan Wenger' <[email-masked]<mailto:[email-masked]>>; 'IETF AVTCore WG' <[email-masked]<mailto:[email-masked]>>; 'shuaiizhao(Shuai Zhao)' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Ye-Kui,

BR,
Miska

From: Ye-Kui Wang <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, September 7, 2021 5:53 AM
To: Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]<mailto:[email-masked]>>; 'Sanchez de la Fuente, Yago' <[email-masked]<mailto:[email-masked]>>
Cc: 'Stephan Wenger' <[email-masked]<mailto:[email-masked]>>; 'IETF AVTCore WG' <[email-masked]<mailto:[email-masked]>>; 'shuaiizhao(Shuai Zhao)' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [External] Re: [AVTCORE] Comments on “RTP Payload Format for Versatile Video Coding (VVC)”

Hi Miska,

BR, YK

Hi Ye-Kui,

BR,
Miska

Hi Ye-Kui,

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

Hi Miska, Yago,

Am I missing something?

BR, YK

Hi Yago,

BR,
Miska

Dear Miska,

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

Hi Ye-Kui,

Hi Miska, Yago, Stephan,

BR, YK

  *   In my understanding:

So

Best Regards,
Miska

---

From: "Sanchez de la Fuente, Yago" <[email-masked]>
Date: Fri, 10 Sep 2021 09:08:36 +0000

Hi Miska,

Thanks for bringing this up again. Please see inline for items 2 and 5.

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

On 10. Sep 2021, at 08:19, Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ye-Kui, all,

[YS] I think that something similar to what we are defining for SPS and VPS consistency  is required for the PTLs in the DCI (probably that is meant by Stephan with “non-contradictory information”). With respect to "If a DCI NAL unit contains multiple PTLs, the sender needs to derive the profile-id from SPS or VPS.”, in section 7 we specify that

1) The
         container NAL unit is an SPS, the bitstream is a single-layer
         bitstream, and the profile_tier_level( ) syntax structures in
         all SPSs referenced by the CVSs in the bitstream has the same
         values respectively for those PTL syntax elements;

 [YS] So in this case all PTLs in different SPSs (or VPSs) would be the same values and I think that then there would not be different PTLs in a DCI NAL unit. Anyhow, IMO if we specify “non-contradictory information” similar to what we’ve done for SPS and VPS consistency for the PTLs in the DCI NAL unit things should work. Does it make sense?

  *   In my understanding:

[YS] I do not have a strong opinion here. The idea of having an inference value is for the case that a VPS is sent and no sprop-ols-id is included. Note that currently we do not allow recv-ols-id to be present in the answer so for a receiver to determine whether it is able to accept the offer it should know which operating point is offered. Otherwise, we would have to require in this case recv-ols-id to be present right?

So

BR,
Miska

Hi Miska,

BR, YK

Hi Ye-Kui,

BR,
Miska

Hi Miska,

BR, YK

Hi Ye-Kui,

BR,
Miska

Hi Ye-Kui,

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

Hi Miska, Yago,

Am I missing something?

BR, YK

Hi Yago,

BR,
Miska

Dear Miska,

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

Hi Ye-Kui,

BR,
Miska

Hi Miska, Yago, Stephan,

BR, YK

  *   In my understanding:

So

Best Regards,
Miska

---

From: "Hannuksela, Miska (Nokia - FI/Tampere)" <[email-masked]>
Date: Mon, 20 Sep 2021 13:58:10 +0000

Hi Yago,

Fully agreed on item 2.

On item 5, I think the question is: When there is neither sprop-ols-id in the offer nor recv-ols-id in the answer, what is the implied semantics?

The current I-D  infers sprop-ols-id to be equal to TargetOlsIdx as specified in VVC but, in my opinion, is not clear on recv-ols-id. The phrasing is “When not present, the value of recv-ols-id is inferred to be equal to the value of the sprop-ols-id parameter in the SDP offer”, which I interpret to mean that when sprop-ols-id is present and recv-ols-id is absent, then recv-ols-id is inferred to be equal to sprop-ols-id.

I can think of the following options of fixing this:
1. When sprop-vps is present in an offer but there is neither sprop-ols-id in the offer nor recv-ols-id in the answer, the sender MAY send any output layer set in sprop-vps. Additionally, keep the current requirement that recv-ols-id is only allowed when sprop-ols-id is present and delete the inference for sprop-ols-id value, when it is not present.

2. When recv-ols-id is not present, the value of recv-ols-id is inferred to be equal to value of the sprop-ols-id parameter inferred from or indicated in the SDP offer. Additionally, keep the inference for sprop-ols-id value, when it is not present.

3. When sprop-vps is present and sprop-ols-id is absent in an offer:
* The absence of recv-ols-id in the answer indicates that the receiver has no preference among the output layer sets and the sender MAY send any output layer set in sprop-vps.
* recv-ols-id may be present in the answer to indicate receiver’s choice of the declared output layer sets in sprop-vps.
Additionally, delete the inference for sprop-ols-id value, when it is not present.

I tend to like option 2 the least, because it causes the VVC RTP payload  implementation to have a dependency on the VVC decoding process.

Best Regards,
Miska

Sent: Friday, September 10, 2021 12:09 PM

Hi Miska,

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

Hi Ye-Kui, all,

1) The

  *   In my understanding:

So

BR,
Miska
…

---

From: "Sanchez de la Fuente, Yago" <[email-masked]>
Date: Tue, 21 Sep 2021 08:49:19 +0000

Hi Miska,

Thanks a lot for your reply. Good point on item 5. I also agree with you and like your suggested on option 2. We will fix that as suggested.

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

On 20. Sep 2021, at 15:58, Hannuksela, Miska (Nokia - FI/Tampere) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Yago,

Fully agreed on item 2.

2. When recv-ols-id is not present, the value of recv-ols-id is inferred to be equal to value of the sprop-ols-id parameterinferred from or indicated in the SDP offer. Additionally, keep the inference for sprop-ols-id value, when it is not present.

Best Regards,
Miska

Hi Miska,

Best regards,
Yago Sánchez

---

Tel.: +49 30 310 02663

Hi Ye-Kui, all,

1) The

  *   In my understanding:

So

BR,
Miska
…