Re: [MMUSIC] 3D drafts and their relevancy

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

>> I would like to ask the group whether it believes it is beneficial to
continue specification of 3D in SDP/SIP?

 

I, too,  believe that a specification for 3D video is worth considering. 

 

>From an application standpoint, 3d video streaming and 3d video
calls/conferences should be viable in the near future, if they aren't
already. Regarding streaming, there's plenty of 3D content currently
available, with more created every day, and sales of 3D screens also seem to
be on the rise. 3D conferencing may have to wait a bit more,  since 3D
glasses and video calls don't work that well together, and the most popular
autostereoscopic device out there (the 3DS) is lacking a front-facing 3D
camera - but I'd say it's just a matter of time. 

 

Then there's the issue of the video formats. MVC is obviously appealing,
and its usage with SDP will be specified in
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-mvc/ . The
alternative formats described in Bert's draft and in mine (simulcast,
video+depth, frame-packing) are, by comparison, less sophisticated and
efficient, but not necessarily (as some have suggested) obsolete. Also, the
fact that some of them have been adopted by other standardization bodies
should be taken into account. 

 

Some comments on each individual 3D format:

-          Simulcast, or sending each video view as  an independent 2D video
stream over separate RTP sessions, is the trivial solution for transporting
3D video. It's bandwidth requirements are as inefficient as it gets, and
likely prohibitive for any system using 3+ views. On the upside, it is
fairly easy to implement,  is codec-independent, and doesn't require much
processing power (unlike more complex schemes like MVC). At the very least,
this should be a decent format for mobile 3D applications requiring 2 views.

-          Video plus depth, or sending one 2D video view along with a depth
map stream, is a standard format specified as MPEG-C part 3.  In this
format, the depth map video stream is transmitted as auxiliary data
encapsulated within the video stream for the base view. Video+depth is
backwards compatible, and falls between simulcast and MVC in terms of
complexity and efficiency.  

-          Frame-packing formats are used to multiplex 2 video views as a
single video stream. This is sometimes required to transmit 3D streams
through legacy equipment. The format is as inefficient as simulcast, and
introduces a loss of spatial or temporal resolution, due to the
multiplexing. Frame-packing has been adopted by the DVB 3DTV standard, and
is also used in HDMI. That said, I'm having a hard time finding a
justification for this format in a SIP environment, as it doesn't seem to
have a clear advantage over any of the alternatives.

It is important to note that a draft could specify just a subset of these
formats, if any of them is evaluated as not relevant enough.

 

Best regards,

Pedro

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Bert Greevenbosch
Sent: Friday, October 12, 2012 8:20 AM
To: [e-mail]
Subject: [MMUSIC] 3D drafts and their relevancy

 

Hello all,

 

During the Vancouver meeting, the 3D drafts were briefly discussed:

 

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

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

 

(I can't find them on the MMUSIC page anymore. Can the link be re-inserted,
as they have not been expired yet?)

 

During the discussion, there were some concerns about the relevancy of the
drafts, especially with the existence of MVC.

 

The frame packing formats have been adopted in HDMI 1.4a and DVB 3DTV
standards, both of which are quite recent. Also depth maps are gaining more
interest in the research community, as they provide a nice and concise way
to supply additional 3D information along with a 2D video stream.

 

Moreover, the drafts are not intended as an alternative to MVC. It is just
about providing signalling for codecs that are already in existence today.

 

I feel it would be a pity to stop working on 3D in SDP/SIP now. I believe
having SDP signalling would be quite helpful not just for one-directional
use cases, but especially also for 3D conversational use cases. The arrival
of the first 3D-glasses-free handhelds shows that comfortable 3D
conversation can be achieved in the near future.

 

I would like to ask the group whether it believes it is beneficial to
continue specification of 3D in SDP/SIP?

 

Thanks in advance for your opinions!

 

Best regards,

Bert