Subject: [avtext] Fwd: draft response to SA4 liaison statement

From: Jonathan Lennox <[email-masked]>
Date: Tue, 8 Sep 2015 15:15:08 +0000

Hello, AVTExt members —

Here is Roni Even’s proposed response to SA4’s liaison statement about Video Region-of-Interest.  Please review and comment.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 9 Sep 2015 09:04:28 +0000

1)	Please add IETF in front of "AVText WG" in source.

2)	The paragraph labelled "Overall" confused me until I realized it was repeating the input points from SA4. We should use a more appropriate title such as "3GPP SA4 request".

3)	I believe this LS needs to be more specific on what an aligned result is. Depending on interpretation, an aligned specification can still fail to interoperate. Do we plan that any IETF specification in this area and any 3GPP specification in this area should interoperate?

Regards

Keith

-----Original Message-----
From: avtext [mailto:[email-masked]] On Behalf Of Jonathan Lennox
Sent: 08 September 2015 16:15
To: [email-masked]
Subject: [avtext] Fwd: draft response to SA4 liaison statement

Hello, AVTExt members —

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 9 Sep 2015 16:00:59 +0200

Hi,

I have looked at the draft LS. I think we should provide constructive 
feedback for what the AVTEXT participants see as shortcomings of the 
3GPP proposals. I think the main reason for considering to do IETF work 
on this was that the proposal had shortcomings.

I will note that 3GPP has already requested registration for their RTP 
header extensions as well as the RTCP Feedback format. I am reviewer and 
have had some feedback to them. They are likely to need to revise their 
specification to fulfil this requirement.

Therefore I think they can consider to address a larger set of feedbacks 
if we can provide it. I personally don't see a need for an IETF 
specification if the 3GPP one is sufficiently good.

The primary issue I saw with the feedback format is that it is unclear 
if the FCI format allows for multiple entries.

However, I think there might be an issue with determining if a request 
is being received and acted on. That is clearly one difference between 
the I-D here in IETF and the 3GPP spec.

Thus, I think we should gather such feedback and provide it.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Roni Even" <[email-masked]>
Date: Wed, 9 Sep 2015 19:58:04 +0300

Hi,
My understanding was that the authors of the IETF document were asked to go
to 3GPP and present their concerns over there. Since the authors do not
attend 3GPP meeting and they have concerns with the proposed solution, I
believe that this is what we can currently say.
If you think we should raise our concerns I can point at the three major
ones.

1. It is not clear what is the "original content ". Is it the first image
that was sent, how does it work for multipoint? We think that the request
can relate to the current content as the reference for the request.
2. The co-ordinates can be negative if you want to zoom out or move out of
the displayed content (this also relates to the first issue of what is the
original content)
3. The definition of pre-defined is not clear depending on the definition of
"original content". BTW: in H.281 the pre-defined are using a current view
and provide an ID for it that can be used later to return to the same view

Roni Even

-----Original Message-----
From: avtext [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Wednesday, September 09, 2015 5:01 PM
To: Jonathan Lennox; [email-masked]
Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement

Hi,

I have looked at the draft LS. I think we should provide constructive
feedback for what the AVTEXT participants see as shortcomings of the 3GPP
proposals. I think the main reason for considering to do IETF work on this
was that the proposal had shortcomings.

Therefore I think they can consider to address a larger set of feedbacks if
we can provide it. I personally don't see a need for an IETF specification
if the 3GPP one is sufficiently good.

The primary issue I saw with the feedback format is that it is unclear if
the FCI format allows for multiple entries.

However, I think there might be an issue with determining if a request is
being received and acted on. That is clearly one difference between the I-D
here in IETF and the 3GPP spec.

Cheers

Magnus Westerlund

_______________________________________________
avtext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/avtext

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Sep 2015 10:13:12 +0200

> can relate to the current content as the reference for the request.

Yes, this is thorny and I think you will need to expand on this. It 
clearly need to work with switched sources, such as the ones in an RTP 
mixer performing source switching. I think one can also raise the issue 
between original capture and what is being encoded, as scaling prior to 
encoding for bit-rate adaptation and simulcast usage makes things more 
interesting. As the coordinates in pixel in these cases for a particular 
region changes upon the switch of resolution.

> the displayed content (this also relates to the first issue of what is the

Given, that the coordinate system is in relation to the currently 
received picture. But, I do note that attempting to use "current" 
requires one to include some type of reference (RTP Timestamp), for what 
current is, due to the delay between the sender side and receiver.

> and provide an ID for it that can be used later to return to the same view

Okay, this needs to be written up in an more complete argumentation.

I also note that these type of issues do result in an highly likelihood 
that an updated specification, independently if it is in 3GPP and IETF 
this specification is developed. Thus, we might be forced to raise the 
warning that this might be the end result.

Cheers

Magnus Westerlund

-- 

Magnus Westerlund

---

From: "Roni Even" <[email-masked]>
Date: Thu, 10 Sep 2015 17:11:02 +0300

Hi,
Thanks Magnus, so the question about the Liaison will be if it should have
all these concerns. I do not think that this should be as comments to the
IANA registration request.
On the other hand I am not sure what it will help by having the particular
concerns in the response to the liaison from 3GPP since they did not ask for
comments on their document and it is not clear that they will act on it.

Roni

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Thursday, September 10, 2015 11:13 AM
To: Roni Even; 'Jonathan Lennox'; [email-masked]
Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement

Den 2015-09-09 kl. 18:58, skrev Roni Even:
> Hi,
> My understanding was that the authors of the IETF document were asked 
> to go to 3GPP and present their concerns over there. Since the authors 
> do not attend 3GPP meeting and they have concerns with the proposed 
> solution, I believe that this is what we can currently say.
> If you think we should raise our concerns I can point at the three 
> major ones.
>
> 1. It is not clear what is the "original content ". Is it the first 
> image that was sent, how does it work for multipoint? We think that 
> the request can relate to the current content as the reference for the
request.

Yes, this is thorny and I think you will need to expand on this. It clearly
need to work with switched sources, such as the ones in an RTP mixer
performing source switching. I think one can also raise the issue between
original capture and what is being encoded, as scaling prior to encoding for
bit-rate adaptation and simulcast usage makes things more interesting. As
the coordinates in pixel in these cases for a particular region changes upon
the switch of resolution.

> 2. The co-ordinates can be negative if you want to zoom out or move 
> out of the displayed content (this also relates to the first issue of 
> what is the original content)

Given, that the coordinate system is in relation to the currently received
picture. But, I do note that attempting to use "current" 
requires one to include some type of reference (RTP Timestamp), for what
current is, due to the delay between the sender side and receiver.

> 3. The definition of pre-defined is not clear depending on the 
> definition of "original content". BTW: in H.281 the pre-defined are 
> using a current view and provide an ID for it that can be used later 
> to return to the same view

I also note that these type of issues do result in an highly likelihood that
an updated specification, independently if it is in 3GPP and IETF this
specification is developed. Thus, we might be forced to raise the warning
that this might be the end result.

Cheers

Magnus Westerlund

> 3GPP proposals. I think the main reason for considering to do IETF 
> work on this was that the proposal had shortcomings.
>
> header extensions as well as the RTCP Feedback format. I am reviewer 
> and have had some feedback to them. They are likely to need to revise 
> their specification to fulfil this requirement.
>
> Therefore I think they can consider to address a larger set of 
> feedbacks if we can provide it. I personally don't see a need for an 
> IETF specification if the 3GPP one is sufficiently good.
>

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 11 Sep 2015 11:12:39 +0200

Hi,

My point is that we appear to have some significant issues with what is 
currently specified in 3GPP. If AVTEXT would take on ROI work it is 
likely that these would result in a non-backwards compatible solution. 
That I think is highly relevant in regards to the ACTION part of the LS:

"3GPP SA4 kindly requests IETF to take the information above into 
account, and maintain coordination with SA4 during the course of the 
development of draft-huang-avtext-feedback-image-control-00 toward 
ensuring the alignment between 3GPP and IETF specifications."

This would affect alignment. Thus, I am of the opinion that we need to 
raise this issue at the start to avoid future issues around divergent 
expectations.

I do need to note that SA4 have approved some changes to their 
specification, which can be seen here until they are integrated in the 
next version of their specification:

http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_85/Docs/S4-151080.zip

This do clarify at least parts of the issues raised.

In regards to the IANA registrations, these changes do result that the 
RTP header extension requests can go forward.

Cheers

Magnus Westerlund

-- 

Magnus Westerlund

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 11 Sep 2015 10:23:55 +0000

More fundamental, it is not clear to me whether AVTEXT intend themselves to work on this subject because they see it as of general application, or whether those interested are only interested in the context of an IMS media. The former should generate IETF documentation. For the latter, we only need to ensure it in accordance with the RTP documentation and coding rules.

>From listening to the audio stream remotely, I do not think this was really discussed in Prague, and it does not seem to have been addressed on the mailing list.

If we want a general solution documented by IETF, our response to IETF needs to be very different to Roni's original response, and address the IETF documentation needs and how we would intend to do that.

For information, the 3GPP work is release 13, and the release 13 freeze date is the end of this year.

Regards

Keith

-----Original Message-----
From: avtext [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: 11 September 2015 10:13
To: Roni Even; 'Jonathan Lennox'; [email-masked]
Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement

Hi,

My point is that we appear to have some significant issues with what is currently specified in 3GPP. If AVTEXT would take on ROI work it is likely that these would result in a non-backwards compatible solution. 
That I think is highly relevant in regards to the ACTION part of the LS:

"3GPP SA4 kindly requests IETF to take the information above into account, and maintain coordination with SA4 during the course of the development of draft-huang-avtext-feedback-image-control-00 toward ensuring the alignment between 3GPP and IETF specifications."

This would affect alignment. Thus, I am of the opinion that we need to raise this issue at the start to avoid future issues around divergent expectations.

I do need to note that SA4 have approved some changes to their specification, which can be seen here until they are integrated in the next version of their specification:

In regards to the IANA registrations, these changes do result that the RTP header extension requests can go forward.

Cheers

Magnus Westerlund

Den 2015-09-10 kl. 16:11, skrev Roni Even:
> Hi,
> Thanks Magnus, so the question about the Liaison will be if it should 
> have all these concerns. I do not think that this should be as 
> comments to the IANA registration request.
> On the other hand I am not sure what it will help by having the 
> particular concerns in the response to the liaison from 3GPP since 
> they did not ask for comments on their document and it is not clear that they will act on it.
>
> Roni
>
>> to go to 3GPP and present their concerns over there. Since the 
>> authors do not attend 3GPP meeting and they have concerns with the 
>> proposed solution, I believe that this is what we can currently say.
> mixer performing source switching. I think one can also raise the 
> issue between original capture and what is being encoded, as scaling 
> prior to encoding for bit-rate adaptation and simulcast usage makes 
> things more interesting. As the coordinates in pixel in these cases 
> for a particular region changes upon the switch of resolution.
>
> requires one to include some type of reference (RTP Timestamp), for 
> what current is, due to the delay between the sender side and receiver.
>
> I also note that these type of issues do result in an highly 
> likelihood that an updated specification, independently if it is in 
> 3GPP and IETF this specification is developed. Thus, we might be 
> forced to raise the warning that this might be the end result.
>
> Cheers
>
> Magnus Westerlund
>
>>
>> Roni Even
>>
>> I will note that 3GPP has already requested registration for their 
>> RTP header extensions as well as the RTCP Feedback format. I am 
>> reviewer and have had some feedback to them. They are likely to need 
>> to revise their specification to fulfil this requirement.
>>
>> The primary issue I saw with the feedback format is that it is 
>> unclear if the FCI format allows for multiple entries.
>>
>> However, I think there might be an issue with determining if a 
>> request is being received and acted on. That is clearly one 
>> difference between the I-D here in IETF and the 3GPP spec.
>>
>> ---------------------------------------------------------------------
>> - Services, Media and Network features, Ericsson Research EAB/TXM

-- 

Magnus Westerlund

---

From: "Roni Even" <[email-masked]>
Date: Fri, 11 Sep 2015 16:47:21 +0300

Hi Magnus,
I looked at the changes and I am not sure they clarify the issues. 
For example : Position_X - specifies the x-coordinate for the upper left
corner of the ROI area covered in the original content (i.e., uncompressed
captured content) in units of pixels - this is still not clear.  Two points:
1. Uncompressed capture content - is not clear, it does not say at which
zoom the camera was using for the uncompressed and when it was taken
2. In this case the units should not be pixels but arbitrary co-ordinates -
I think that comment was made by Randell Jesup in Prague.

I think that one of the major issues is that the design does not look at the
way ROI application will work which in my view may typically be based on the
video receiver select  an area of interest on the current screen or use the
mouse to drag the image (left right, up, down) and ask for refresh for pan
for example, so it will be better to base the request on a current view
(maybe using RTP time stamp) instead to some "original content".  

Roni

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Friday, September 11, 2015 12:13 PM
To: Roni Even; 'Jonathan Lennox'; [email-masked]
Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement

Hi,

My point is that we appear to have some significant issues with what is
currently specified in 3GPP. If AVTEXT would take on ROI work it is likely
that these would result in a non-backwards compatible solution. 
That I think is highly relevant in regards to the ACTION part of the LS:

"3GPP SA4 kindly requests IETF to take the information above into account,
and maintain coordination with SA4 during the course of the development of
draft-huang-avtext-feedback-image-control-00 toward ensuring the alignment
between 3GPP and IETF specifications."

This would affect alignment. Thus, I am of the opinion that we need to raise
this issue at the start to avoid future issues around divergent
expectations.

I do need to note that SA4 have approved some changes to their
specification, which can be seen here until they are integrated in the next
version of their specification:

In regards to the IANA registrations, these changes do result that the RTP
header extension requests can go forward.

Cheers

Magnus Westerlund

Den 2015-09-10 kl. 16:11, skrev Roni Even:
>> -

-- 

Magnus Westerlund

---

From: Bo Burman <[email-masked]>
Date: Tue, 15 Sep 2015 15:07:24 +0000

Roni, Magnus,

I agree that there are likely flaws and/or incompleteness in the ROI specification in 3GPP. I would however expect that 3GPP welcomes constructive feedback from IETF. I think neither IETF nor 3GPP will benefit from having conflicting ROI specifications.

Please find my comments inline below (including comments to Roni's original list of issues).

Cheers,
Bo

> From: avtext [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: den 11 september 2015 15:47
> To: Magnus Westerlund; 'Jonathan Lennox'; [email-masked]
> For example : Position_X - specifies the x-coordinate for the upper left corner of the ROI area covered in the original
> content (i.e., uncompressed captured content) in units of pixels - this is still not clear.  Two points:
> 1. Uncompressed capture content - is not clear, it does not say at which zoom the camera was using for the
> uncompressed and when it was taken 
[BoB] I don't think there is any issue here. The latest agreed update in the document Magnus provided a link to includes the following statement:
"The SDP offer with a=predefined_ROI parameter shall contain the full-size view of the video indicated via ROI_ID=0."
That is, ID 0 always provides the frame of reference by providing a  fully zoomed-out view of the area referred by other ROI definitions.
Note that this is only applicable to the pre-defined ROI mode, where the video receiver chooses a pre-defined area by name, not by coordinates. It is the video sender that provides the coordinates of the pre-defined areas, not the video receiver. That is fully clear from the existing 3GPP text.

2. In this case the units should not be pixels but arbitrary co-ordinates - I think that
> comment was made by Randell Jesup in Prague.
[BoB] Since the frame of reference is always provided, it does not matter what units are used, and can coordinates very well be considered to be "arbitrary co-ordinates".

> 
> I think that one of the major issues is that the design does not look at the way ROI application will work which in my view
> may typically be based on the video receiver select  an area of interest on the current screen or use the mouse to drag
> the image (left right, up, down) and ask for refresh for pan for example, so it will be better to base the request on a
> current view (maybe using RTP time stamp) instead to some "original content".
[BoB] I don't understand that objection. The "Arbitrary ROI" mode describes exactly, or at least something very similar to that mode of operation. It makes use of a new rtcp-fb format ("3gpp-roi-arbitrary") allowing the video receiver to request a selected area of the video to be sent, in conjunction with an RTP Header Extension ("urn:3gpp:roi-sent") from the video sender describing what area that is currently included in the RTP payload. The coordinates in both the request and the announcement express upper left corner and a size, and I don't understand "original content" to be directly related to any fixed reference frame. Instead, the video receiver is expected to look at what is region is actually sent in the RTP HE and construct the RTCP feedback from that. Zooming out would simply involve increasing the size values in the RTCP feedback. I expect that 16 bits per size component is plenty in that aspect. Panning involves moving the upper left corner reference in the request compared to what is received in the RTP HE.

> My point is that we appear to have some significant issues with what is currently specified in 3GPP. If AVTEXT would take
> on ROI work it is likely that these would result in a non-backwards compatible solution.
> "3GPP SA4 kindly requests IETF to take the information above into account, and maintain coordination with SA4 during
> the course of the development of
> draft-huang-avtext-feedback-image-control-00 toward ensuring the alignment between 3GPP and IETF specifications."
> 
> I do need to note that SA4 have approved some changes to their specification, which can be seen here until they are
> integrated in the next version of their specification:
> 
> > they did not ask for comments on their document and it is not clear
> > that
> they will act on it.
[BoB] I do think that 3GPP will act on constructive feedback.

> > for a particular region changes upon the switch of resolution.
[BoB] See my comments above. "Original content" basically apply only to pre-defined ROI, in which case the "full" reference frame is given by the pre-defined ID 0. I do agree that the 3GPP text lacks considerations related to ROI use in conferencing situations, but lack of explicit descriptions related to conferencing / multiparty situations is true for that entire specification (not only the ROI part). I think you must read and understand the current text as basically applicable only for point-to-point. I believe parts of Magnus' concerns are handled by relating the RTCP FB request to what is actually sent, which can be learnt through the RTP HE. It however seems to me that ROI requests on content received from an RTP Mixer is not covered by and thus likely not in scope for the current 3GPP text.

> > what current is, due to the delay between the sender side and receiver.
[BoB] I don't expect that precision of reference is necessary. Remember that 3GPP mainly deals with mobile terminals and thus a non-fixed camera. I don't expect that the terminal in general can or will track and save the capture area dynamically, so even if it receives a request for "give me this video area relative to what you sent 785 ms ago", it will hardly be able to comply (at least not with any precision).
Zooming out does not require negative coordinates, just increasing the size in the request compared to what is announced as received. Moving out of the displayed content will work fine, as long as it does not reach the upper or left edge, that is agreed. This can be counter-acted by the video sender by announcing an upper and left edge in the RTP HE that is some way off the value 0.

> > Okay, this needs to be written up in an more complete argumentation.
[BoB] As said above, I don't think this is an issue, considering the latest updates in the document linked by Magnus.

---

From: "Roni Even" <[email-masked]>
Date: Tue, 15 Sep 2015 21:17:16 +0300

Hi Bo,
Inline
Roni

-----Original Message-----
From: Bo Burman [mailto:[email-masked]] 
Sent: Tuesday, September 15, 2015 6:07 PM
To: Roni Even; Magnus Westerlund; 'Jonathan Lennox'; [email-masked]
Subject: RE: [avtext] Fwd: draft response to SA4 liaison statement

Roni, Magnus,

I agree that there are likely flaws and/or incompleteness in the ROI
specification in 3GPP. I would however expect that 3GPP welcomes
constructive feedback from IETF. I think neither IETF nor 3GPP will benefit
from having conflicting ROI specifications.

Please find my comments inline below (including comments to Roni's original
list of issues).

Cheers,
Bo

> For example : Position_X - specifies the x-coordinate for the upper 
> left corner of the ROI area covered in the original content (i.e.,
uncompressed captured content) in units of pixels - this is still not clear.
Two points:
> 1. Uncompressed capture content - is not clear, it does not say at 
> which zoom the camera was using for the uncompressed and when it was 
> taken
[BoB] I don't think there is any issue here. The latest agreed update in the
document Magnus provided a link to includes the following statement:
"The SDP offer with a=predefined_ROI parameter shall contain the full-size
view of the video indicated via ROI_ID=0."
That is, ID 0 always provides the frame of reference by providing a  fully
zoomed-out view of the area referred by other ROI definitions.

[RE] this is not feasible since you assume that the camera is capturing a
full view. This may not be the case always since camera initial zoom may
depends on user interaction or some setting. Even more, the full view does
not mean that the camera is pointing at the relevant picture, again it is
user dependent. The only way it will work is if the user sending the video
will set the correct view and only after will use the UI to make this the
original picture. BTW: the whole text is confusing using server client
sender and receiver terms for the same thing.

Note that this is only applicable to the pre-defined ROI mode, where the
video receiver chooses a pre-defined area by name, not by coordinates. It is
the video sender that provides the coordinates of the pre-defined areas, not
the video receiver. That is fully clear from the existing 3GPP text.

I think that
> comment was made by Randell Jesup in Prague.
[BoB] Since the frame of reference is always provided, it does not matter
what units are used, and can coordinates very well be considered to be
"arbitrary co-ordinates".

[RE] this had to do with SVC or simulcast when the user can receive lower
resolution

> 
> I think that one of the major issues is that the design does not look 
> at the way ROI application will work which in my view may typically be 
> based on the video receiver select  an area of interest on the current 
> screen or use the mouse to drag the image (left right, up, down) and ask
for refresh for pan for example, so it will be better to base the request on
a current view (maybe using RTP time stamp) instead to some "original
content".

[BoB] I don't understand that objection. The "Arbitrary ROI" mode describes
exactly, or at least something very similar to that mode of operation. It
makes use of a new rtcp-fb format ("3gpp-roi-arbitrary") allowing the video
receiver to request a selected area of the video to be sent, in conjunction
with an RTP Header Extension ("urn:3gpp:roi-sent") from the video sender
describing what area that is currently included in the RTP payload. The
coordinates in both the request and the announcement express upper left
corner and a size, and I don't understand "original content" to be directly
related to any fixed reference frame. Instead, the video receiver is
expected to look at what is region is actually sent in the RTP HE and
construct the RTCP feedback from that. Zooming out would simply involve
increasing the size values in the RTCP feedback. I expect that 16 bits per
size component is plenty in that aspect. Panning involves moving the upper
left corner reference in the request compared to what is received in the RTP
HE.
[RE] I was saying that in this case the co-ordinate may be negative and not
only positive if the reverence is to the current view for the pan. As for
zooming, is it a zoom factor or the new coordinates to be displayed. Using
co-ordinates is more flexible than using zoom factor (two or one dimension
information)

> My point is that we appear to have some significant issues with what 
> is currently specified in 3GPP. If AVTEXT would take on ROI work it is
> development of
expectations.
> > Thanks Magnus, so the question about the Liaison will be if it 
> > should have all these concerns. I do not think that this should be 
> > as comments to the IANA registration request.

> >> My understanding was that the authors of the IETF document were 
> >> asked to go to 3GPP and present their concerns over there. Since 
> >> the authors do not attend 3GPP meeting and they have concerns with 
> >> the proposed solution, I believe that this is what we can currently
say.
> > clearly need to work with switched sources, such as the ones in an 
> > RTP mixer performing source switching. I think one can also raise 
> > the issue between original capture and what is being encoded, as 
> > scaling prior to encoding for bit-rate adaptation and simulcast 
> > usage makes things more interesting. As the coordinates in pixel in 
> > these cases for a particular region changes upon the switch of
resolution.
[BoB] See my comments above. "Original content" basically apply only to
pre-defined ROI, in which case the "full" reference frame is given by the
pre-defined ID 0. I do agree that the 3GPP text lacks considerations related
to ROI use in conferencing situations, but lack of explicit descriptions
related to conferencing / multiparty situations is true for that entire
specification (not only the ROI part). I think you must read and understand
the current text as basically applicable only for point-to-point. I believe
parts of Magnus' concerns are handled by relating the RTCP FB request to
what is actually sent, which can be learnt through the RTP HE. It however
seems to me that ROI requests on content received from an RTP Mixer is not
covered by and thus likely not in scope for the current 3GPP text.

> >> out of the displayed content (this also relates to the first issue 
> >> of what is the original content)
> >
[BoB] I don't expect that precision of reference is necessary. Remember that
3GPP mainly deals with mobile terminals and thus a non-fixed camera. I don't
expect that the terminal in general can or will track and save the capture
area dynamically, so even if it receives a request for "give me this video
area relative to what you sent 785 ms ago", it will hardly be able to comply
(at least not with any precision).
Zooming out does not require negative coordinates, just increasing the size
in the request compared to what is announced as received. Moving out of the
displayed content will work fine, as long as it does not reach the upper or
left edge, that is agreed. This can be counter-acted by the video sender by
announcing an upper and left edge in the RTP HE that is some way off the
value 0.

> >> using a current view and provide an ID for it that can be used 
> >> later to return to the same view
> >
[BoB] As said above, I don't think this is an issue, considering the latest
updates in the document linked by Magnus.

> >> I have looked at the draft LS. I think we should provide 
> >> constructive feedback for what the AVTEXT participants see as 
> >> shortcomings of the 3GPP proposals. I think the main reason for 
> >> considering to do IETF work on this was that the proposal had
shortcomings.
> >> reviewer and have had some feedback to them. They are likely to 
> >> need to revise their specification to fulfil this requirement.
> >>
> >> feedbacks if we can provide it. I personally don't see a need for 
> >> an IETF specification if the 3GPP one is sufficiently good.
> >>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 15 Sep 2015 22:52:44 +0000

Your comments are assuming there will be a parallel IETF specification.

Noone has responded to my earlier question as to whether IETF (and therefore AVTEXT) should produce a specification. I do not think this aspect was discussed in Prague.

If IETF does produce a specification, what is the hoped for relationship to the 3GPP specification.

Regards

Keith

-----Original Message-----
From: avtext [mailto:[email-masked]] On Behalf Of Roni Even
Sent: 15 September 2015 19:17
To: 'Bo Burman'; 'Magnus Westerlund'; 'Jonathan Lennox'; [email-masked]
Subject: Re: [avtext] Fwd: draft response to SA4 liaison statement

Hi Bo,
Inline
Roni

-----Original Message-----
From: Bo Burman [mailto:[email-masked]]
Sent: Tuesday, September 15, 2015 6:07 PM
To: Roni Even; Magnus Westerlund; 'Jonathan Lennox'; [email-masked]
Subject: RE: [avtext] Fwd: draft response to SA4 liaison statement

Roni, Magnus,

Cheers,
Bo

[RE] this is not feasible since you assume that the camera is capturing a full view. This may not be the case always since camera initial zoom may depends on user interaction or some setting. Even more, the full view does not mean that the camera is pointing at the relevant picture, again it is user dependent. The only way it will work is if the user sending the video will set the correct view and only after will use the UI to make this the original picture. BTW: the whole text is confusing using server client sender and receiver terms for the same thing.

[RE] this had to do with SVC or simulcast when the user can receive lower resolution

> screen or use the mouse to drag the image (left right, up, down) and 
for refresh for pan for example, so it will be better to base the request on a current view (maybe using RTP time stamp) instead to some "original content".

[BoB] I don't understand that objection. The "Arbitrary ROI" mode describes exactly, or at least something very similar to that mode of operation. It makes use of a new rtcp-fb format ("3gpp-roi-arbitrary") allowing the video receiver to request a selected area of the video to be sent, in conjunction with an RTP Header Extension ("urn:3gpp:roi-sent") from the video sender describing what area that is currently included in the RTP payload. The coordinates in both the request and the announcement express upper left corner and a size, and I don't understand "original content" to be directly related to any fixed reference frame. Instead, the video receiver is expected to look at what is region is actually sent in the RTP HE and construct the RTCP feedback from that. Zooming out would simply involve increasing the size values in the RTCP feedback. I expect that 16 bits per size component is plenty in that aspect. Panning involves moving the upper left corner reference in the request compared to what is received in the RTP HE.
[RE] I was saying that in this case the co-ordinate may be negative and not only positive if the reverence is to the current view for the pan. As for zooming, is it a zoom factor or the new coordinates to be displayed. Using co-ordinates is more flexible than using zoom factor (two or one dimension
information)

expectations.
next version of their specification:
> RTP

say.
resolution.

shortcomings.

---

From: Bo Burman <[email-masked]>
Date: Wed, 16 Sep 2015 07:26:12 +0000

As my first preference, I would hope is not necessary with an IETF specification.

If IETF does produce a specification, I would like it to be directly applicable to what 3GPP requires. That way, when the IETF spec is ready, 3GPP can remove a large chunk of text in their specification and replace it with a reference to the IETF spec. This would in my view keep alignment on a reasonable level.

It would however likely still introduce a compatibility problem, since I expect an IETF spec to end up rather different than what 3GPP specified (even if it is for good reasons).

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: den 16 september 2015 00:53
> To: Roni Even; Bo Burman; Magnus Westerlund; 'Jonathan Lennox'; [email-masked]
> Noone has responded to my earlier question as to whether IETF (and therefore AVTEXT) should produce a specification. I
> do not think this aspect was discussed in Prague.
> 
> I agree that there are likely flaws and/or incompleteness in the ROI specification in 3GPP. I would however expect that
> 3GPP welcomes constructive feedback from IETF. I think neither IETF nor 3GPP will benefit from having conflicting ROI
> specifications.
> 
> [RE] this is not feasible since you assume that the camera is capturing a full view. This may not be the case always since
> camera initial zoom may depends on user interaction or some setting. Even more, the full view does not mean that the
> camera is pointing at the relevant picture, again it is user dependent. The only way it will work is if the user sending the
> video will set the correct view and only after will use the UI to make this the original picture. BTW: the whole text is
> confusing using server client sender and receiver terms for the same thing.
> 
> Note that this is only applicable to the pre-defined ROI mode, where the video receiver chooses a pre-defined area by
> name, not by coordinates. It is the video sender that provides the coordinates of the pre-defined areas, not the video
> receiver. That is fully clear from the existing 3GPP text.
> 
> [BoB] Since the frame of reference is always provided, it does not matter what units are used, and can coordinates very
> well be considered to be "arbitrary co-ordinates".
> 
> [BoB] I don't understand that objection. The "Arbitrary ROI" mode describes exactly, or at least something very similar to
> that mode of operation. It makes use of a new rtcp-fb format ("3gpp-roi-arbitrary") allowing the video receiver to
> request a selected area of the video to be sent, in conjunction with an RTP Header Extension ("urn:3gpp:roi-sent") from
> the video sender describing what area that is currently included in the RTP payload. The coordinates in both the request
> and the announcement express upper left corner and a size, and I don't understand "original content" to be directly
> related to any fixed reference frame. Instead, the video receiver is expected to look at what is region is actually sent in
> the RTP HE and construct the RTCP feedback from that. Zooming out would simply involve increasing the size values in
> the RTCP feedback. I expect that 16 bits per size component is plenty in that aspect. Panning involves moving the upper
> left corner reference in the request compared to what is received in the RTP HE.
> [RE] I was saying that in this case the co-ordinate may be negative and not only positive if the reverence is to the current
> view for the pan. As for zooming, is it a zoom factor or the new coordinates to be displayed. Using co-ordinates is more
> flexible than using zoom factor (two or one dimension
> information)
> 
> >
> >
> > Roni
> >
> [BoB] See my comments above. "Original content" basically apply only to pre-defined ROI, in which case the "full"
> reference frame is given by the pre-defined ID 0. I do agree that the 3GPP text lacks considerations related to ROI use in
> conferencing situations, but lack of explicit descriptions related to conferencing / multiparty situations is true for that
> entire specification (not only the ROI part). I think you must read and understand the current text as basically applicable
> only for point-to-point. I believe parts of Magnus' concerns are handled by relating the RTCP FB request to what is
> actually sent, which can be learnt through the RTP HE. It however seems to me that ROI requests on content received
> from an RTP Mixer is not covered by and thus likely not in scope for the current 3GPP text.
> 
> > >
> [BoB] I don't expect that precision of reference is necessary. Remember that 3GPP mainly deals with mobile terminals
> and thus a non-fixed camera. I don't expect that the terminal in general can or will track and save the capture area
> dynamically, so even if it receives a request for "give me this video area relative to what you sent 785 ms ago", it will
> hardly be able to comply (at least not with any precision).
> Zooming out does not require negative coordinates, just increasing the size in the request compared to what is
> announced as received. Moving out of the displayed content will work fine, as long as it does not reach the upper or left
> edge, that is agreed. This can be counter-acted by the video sender by announcing an upper and left edge in the RTP HE
> that is some way off the value 0.
> 
> > >

---

From: Bo Burman <[email-masked]>
Date: Wed, 16 Sep 2015 08:02:32 +0000

Hi Roni, more inline (with [BoB2]). /Bo

> From: Roni Even [mailto:[email-masked]]
> Sent: den 15 september 2015 20:17
> To: Bo Burman; Magnus Westerlund; 'Jonathan Lennox'; [email-masked]
[BoB2] Why is that not feasible? This is only for the "pre-defined ROI" mode, where the pre-condition is that the sender has defined a set of regions that can be addressed by a type of "shortcut" ID, and where the lowest ID 0 is, per definition, the full view (whatever that is). I can agree that this mode is viable only when the sending user has a fixed camera, or at least temporarily put the camera in a fixed position _and_ somehow manually defined what ROI areas should be offered. The scenario you are advocating for is instead dealt with in the "arbitrary ROI" description.

> [RE] this had to do with SVC or simulcast when the user can receive lower resolution
[BoB2] OK. In the latest 3GPP text, the actual resolution of the sent video is said to be independent of the chosen ROI area, so I don't see any major issue even in the case of SVC or simulcast.

> flexible than using zoom factor (two or one dimension
[BoB2] It is coordinates, a size, not a zoom factor. Panning up and/or to the left could potentially require negative coordinates for upper left corner. This can be mitigated if the RTP HE does not set the "normal" view upper left corner to (0, 0), but starts at a positive offset. That will however at some point run into the situation that it reaches an "edge" in that it is no longer possible to request pan up or left.