Re: [MMUSIC] The 3D drafts

["Pedro Capelastegui" <[e-mail]>]

Hi Bert,

 

Another open issue for the “3d format” draft was the negotiation of sessions
with more than one 3D stream. I discuss it in this mail.

In the current version of the draft, it is possible to set up a session with
multiple 3D streams. An offerer can include several 3D streams in its SDP,
and the answerer can select any number of them. There are rules that prevent
the answerer from selecting more streams than it can process. However,
nothing stops an answerer from selecting more streams than _the offerer_ can
send or receive – in fact, the answerer has no way to know how many streams
can be handled by the offerer.

This can come up even in very simple scenarios. Consider the following
offer:

 

m=video 1111 RTP/AVP 99

a=rtpmap:99 H264/90000

a=3dFormat:FP SbS

m=video 1112 RTP/AVP 99

a=rtpmap:99 H264/90000

a=3dFormat:FP TaB

 

This SDP is intended as an offer of a single 3D stream with 2 possible
configurations: frame-packed side-by-side, and top-bottom. The UA generating
the offer expects the answerer to select only one 3D format. But the
answerer doesn’t know that, and it’s perfectly legal for it to respond by
selecting both 3D formats: 

 

m=video 2222 RTP/AVP 99

a=rtpmap:99 H264/90000

a=3dFormat:FP SbS

m=video 2223 RTP/AVP 99

a=rtpmap:99 H264/90000

a=3dFormat:FP TaB

 

At this point, the offerer is receiving media that it’s not prepared to
handle (which goes against the offer/answer model), and should either
re-invite, or close the session.

 

How to avoid this scenario?

 

The straightforward solution is to forbid answerers from selecting more than
one 3D format altogether. This is certainly effective, but too limiting, as
it rules out the possibility of multi-stream 3D sessions.

 

A better solution would be to create a new  session level attribute
(“a=max3dstreams”) for the offerer to indicate the maximum number of 3D
streams it wants for this session. The default value for this attribute
would be ‘1’, so that the attribute would only be needed for sessions with
multiple streams. 

 

This should cover most scenarios, but there are a few corner cases that are
left unsupported. Consider a user agent that wants to initiate a session
with 2 3D streams, with the constraint that one of the streams needs to have
2 views, and the other needs to have a view and a depth map. This is a rare
scenario, but it can happen if the UA has different 3D screens, one taking
left and right views as input, and the other using video+depth map:

 

a=max3dstreams:2

m=video 1111 RTP/AVP 99

a=rtpmap:99 H264/90000

a=3dFormat:FP SbS

m=video 1112 RTP/AVP 99

a=rtpmap:99 H264/90000

a=3dFormat:FP TaB

m=video 1113 RTP/AVP 99

a=rtpmap:99 H264/90000

a=3dFormat:2DA CD

 

For this UA, an answer selecting “FP SbS” and “2DA CD” as 3d formats, or “FP
TaB” and “2DA CD” would be acceptable, but one with “FP SbS” and “FP  TaB”
would not.

 

We could extend the signalling to cover this kind of scenario (e.g. by
introducing a new type of grouping), but I think this would be too complex,
and not worth the effort. In these cases, the offerer can start by
configuring the session with a single 3D stream, and add any additional 3D
streams in later offer/answer exchanges.

 

Best regards,

Pedro

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Bert Greevenbosch
Sent: Monday, February 06, 2012 1:32 AM
To: IETF - MMUSIC
Subject: [MMUSIC] The 3D drafts

 

Hi all,

 

I was wondering, if everybody is happy with the current versions of the 3D
drafts, or are there still open issues?

I look forward to your comments.

 

Best regards,

Bert

 

http://datatracker.ietf.org/doc/draft-ietf-mmusic-parallax-attribute/

http://datatracker.ietf.org/doc/draft-ietf-mmusic-signal-3d-format/

  _____  

No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com
Versión: 10.0.1424 / Base de datos de virus: 2112/4791 - Fecha de
publicación: 02/05/12