Re: [MMUSIC] Fwd: New Version Notification for draft-abhishek-mmusic-overlay-grouping-00.txt

[Rohit Abhishek <[e-mail]>]

Thanks again Christer for your comments/feedbacks! :-)

Hi Rohit,

>A few initial questions for clarifications:
>RA: The assumption here is for an immersive telepresence session, one immersive video will be transmitted, whereas other streams will be transmitted as overlays. For ex, consider 10 people in a conference call; a
>user may stream an immersive video from one user, whereas 2D videos as overlays from other 8 participants (plus additional streams if any participant shares any additional media) . The total overlay streams may vary, for example, a session with a large number of audiences.
>
>Q1:                      The draft references the telepresence use-case spec (RFC7205), but there is no text on why the actual CLUE mechanism isn’t feasible for what you want to do.
>RA: I had referred to RFC7205 for definition purposes. CLUE enables interoperability between telepresence systems by exchanging information about the systems’ characteristics. Here, the cameras and screens may be arranged to provide a panoramic view of the remote room.  However, overlays were not considered in the CLUE mechanism.

So, spatial relationships etc are outside the scope of what you want to do? You simply want to indicate streams as overlay streams, but the receiving application will decide the order they are rendered in etc.

In addition, the user being able to switch between the main (immersive) video and an overlay is outside the scope?

I think the draft would need to be very clear on what is in the scope – and what isn’t. Also, some text why the CLUE mechanism isn’t used would be useful.


Yes, spatial relationships are currently outside the scope of the proposal.

My apologies for not being clear enough wrt to switching between immersive video and overlays. I do have some related images which I am planning to include in the next version which would definitely bring clarity to what is being proposed here.


>Q2:                      It is unclear why you need to group the overlay streams together. If you only want to indicate that a stream is for overlay you can e.g., use an SDP attribute for that. You don’t need grouping.
>RA: Of course, when a single or relatively fewer overlays are transmitted, grouping won’t be needed. However, when relatively larger numbers of users are in a session, it may be more favorable to use a grouping framework than using SDP attribute for each stream.

Perhaps.

But, before deciding on a mechanism, it needs to be clear what the exact requirement is. And, if I understand correct, the requirement is to indicate that a video stream is an overlay stream?
Yes, the requirement is to indicate that a stream is an overlay stream. I will update the exact requirements in the next version.

>Q3:                      The draft talks about the overlay streams being associated with “immersive video”. But, there is no text about how this immersive video stream is represented, and how the overlay streams are associated with that immersive video stream.
>RA: Thanks for the suggestion. I will update this in the next version
>
>Q4:                      I assume the overlay streams can be multiplexed using the BUNDLE mechanism?
>RA: There maybe multiple RTP sessions whose streams may have to be grouped. Using BUNDLE mechanism will only allow to group media streams within a single RTP session.  However, multiple media streams from various endpoints may be
>multiplexed into a single RTP session but would require RTP-level middle boxes. These middle boxes may add delay if a large number of streams are to be multiplexed, which even if very less, may not be favorable for telepresence sessions.

I guess I was unclear. My suggestion was not to use BUNDLE instead of e.g., your suggested group. But, within such group, there is nothing that prevents overlay streams from being multiplexed?
My understanding is there are limitations which may prevent overlay streams from being multiplexed. Please allow me to investigate more and address this in the next version.


Best Regards,
Rohit

Regards,

Christer





From: mmusic <[e-mail]<mailto:[e-mail]>> On Behalf Of Rohit Abhishek
Sent: keskiviikko 28. lokakuuta 2020 0.23
To: [e-mail]<mailto:[e-mail]>
Subject: [MMUSIC] Fwd: New Version Notification for draft-abhishek-mmusic-overlay-grouping-00.txt

Dear All,

I am currently working on an SDP extension facilitating overlays for immersive telepresence.
An individual draft has been posted at
https://www.ietf.org/archive/id/draft-abhishek-mmusic-overlay-grouping-00.txt

Comments are welcome


Best Regards,
Rohit

---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]>>
Date: Tue, Oct 27, 2020 at 2:56 PM
Subject: New Version Notification for draft-abhishek-mmusic-overlay-grouping-00.txt
To: Rohit Abhishek <[e-mail]<mailto:[e-mail]>>



A new version of I-D, draft-abhishek-mmusic-overlay-grouping-00.txt
has been successfully submitted by Rohit Abhishek and posted to the
IETF repository.

Name:           draft-abhishek-mmusic-overlay-grouping
Revision:       00
Title:          SDP Overlay Grouping framework for immersive telepresence media streams
Document date:  2020-10-27
Group:          Individual Submission
Pages:          8
URL:            https://www.ietf.org/archive/id/draft-abhishek-mmusic-overlay-grouping-00.txt
Status:         https://datatracker.ietf.org/doc/draft-abhishek-mmusic-overlay-grouping/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-abhishek-mmusic-overlay-grouping
Htmlized:       https://tools.ietf.org/html/draft-abhishek-mmusic-overlay-grouping-00


Abstract:
   This document defines semantics that allow for signalling a new SDP
   group "OL" for overlays in an immersive telepresence session.  The
   "OL" attribute can be used by the application to relate all the
   overlay media streams enabling them to be added as overlay on top of
   the immersive video.  The overlay grouping semantics is required, if
   the media data is seperate and transported via different protocols.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat