One document matched: draft-groves-clue-scene-clarifications-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-groves-clue-scene-clarifications-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Abbreviated Title">Discussion of scene and capture scene entry concepts</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Christian Groves" initials="C" role="editor"
surname="Groves">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Melbourne</city>
<region></region>
<code></code>
<country>Australia</country>
</postal>
<email>Christian.Groves@nteczone.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Weiwei Yang" initials="W" role=""
surname="Yang">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>P.R.China</country>
</postal>
<email>tommy@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Roni Even" initials="R" role=""
surname="Even">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Tel Aviv</city>
<region></region>
<code></code>
<country>Isreal</country>
</postal>
<email>roni.even@mail01.huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Paul Kyzivat"
initials="P"
surname="Kyzivat">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<city>Greater Boston</city>
<region>Massachusetts</region>
<code></code>
<country>USA</country>
</postal>
<email>pkyzivat@alum.mit.edu</email>
</address>
</author>
<date year="2012" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>CLUE</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>The CLUE framework document defines the concept of media captures which identify and describe the characteristics of media sent by a provider. A capture scene is a grouping concept that provides ties a number of captures together. Within the capture scene the media captures may further be grouped into capture scene entries. The current text in the CLUE framework document describing these concepts could be improved and clarified so that both providers and consumers use the same logic to encode/decode CLUE messages with capture scenes/ capture scene entries and media captures. This draft discusses these concepts and provides suggested updates.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Recent discussion on the IETF mailing list has indicated that there are different interpretations of exactly what a "Capture Scene Entry" is. In the framework draft it is defined as:</t>
<list hangIndent="10" style="empty"><t>/*Capture Scene Entry: a list of media captures of the same media type that together form one way to represent the capture scene./</t></list>
<t>it also says:</t>
<list hangIndent="10" style="empty"><t>/A media provider arranges media captures in a capture scene to help the media consumer choose which captures it wants. The capture scene entries in a capture scene are different alternatives the provider is suggesting for representing the capture scene./</t></list>
<t>It could be interpreted as meaning that each "Capture Scene Entry" shows an entire scene, or it could be interpreted as meaning that each "Capture Scene Entry" could show part of the overall scene.</t>
<t>It appears from reading the framework both interpretations are allowed. </t>
<t>For example: if VC1,VC2,VC3 are three main cameras, VC4 is an camera that automatically zooms in on the active speaker. One could construct a capture scene with one or two capture scene entries. There are other possibilities but to illustrate the issue the following alternatives are shown:
</t>
<figure align="center" anchor="xml_happy">
<preamble></preamble>
<artwork align="left"><![CDATA[
+------------------+
| Capture Scene #1 |
+------------------+
| VC1, VC2, VC3 |
| VC4 |
+------------------+
or
+--------------------+
| Capture Scene #1 |
+--------------------+
| VC1, VC2, VC3, VC4 |
+--------------------+
]]></artwork>
<postamble></postamble>
</figure>
<t> Depending on how the consumer is designed it may not see the two options as equivalent. In the first example a consumer may only chose the first capture scene entry as it has been designed with the premise that a capture scene entry represents the whole scene and therefore it is sufficient to choose only one line. If it choses one line it missing out on part of the scene. Another consumer may choose both as it recognises multiple capture scene entries. Clearly there is an interoperability problem if the provider and consumer are using different logic to encode / decode captures from scenes. It is also noted that there may be additional complexity for consumers if the method of using capture scene entries to represent partial scenes is used. A consumer would have to parse the characteristcis of each capture to see how they are related.</t>
<t>A further issue is if the entire scene is depicted how does the consumer determine which captures are closely related within a capture scene entry. For example: which of the capture must be processed together to form a continuous image. The area of capture attribute does provide positioning information however determining which captures make up a continuous image may be non-trivial and would become more complicated as the number of captures in a scene entry rose. It would be compounded in situations where different providers have different gaps and scales as there would be different thresholds as to what captures would appear to be continuous. It is believed that having a way to indicated closely bound captures would be advantageous to simplifying this determination.</t>
<t>To add to the complication the framework draft is vague in making recommendations as to what the consumer should do at the reception of scene / capture scene entry / capture information. It suggests that the consumer could pick an element from each of the option presented. It's not clear how this would work under the assumption that a provider provides this information with the understanding to it must be able to simultaneously provide this media. Chosing different captures to what the provider has sent may mean that the media streams related to captures may not be able to sent together. Limiting this flexibility may increase interoperability.</t>
</section>
<section title="Proposal">
<t>This section provides a strawman proposal of principles that should be documented in the framework document</t>
<t>Whilst there appears to be different interpretations, to the Contributors there appears to be one fundamental assumption that everyone agrees on, that is that all captures within a scene must be spatially related.</t>
<t>It is also assumed that there would be a desire to increase the chances of interoperability and to minimise the complexity needed for encoding and parsing scene information.</t>
<t>Based on this assumption and the above discussion it is proposed that : <list hangIndent="8" style="hanging">
<t hangText="a)">A scene represents an area where the capture devices are spatially related, i.e. a presentation that shares no spatial relation with a video is a separate scene.</t>
<t hangText="b)">A capture scene entry thus represents alternate representations of a complete scene. The provider is the one that determines what a complete scene is. A consumer choses a capture scene entry from the scene in the knowledge that it represents the entire scene.</t>
<t hangText="c)">A new concept of "Capture group" be incorporated into a capture scene entry which indicates which captures are closely bound. Closely bound captures are those that have a closer relationship than just being spatially related and MUST be able to be encoded and sent simultaneously. E.g. multiple captures for the purposes of capturing a continuous image or sound stage are closely bound. </t>
<t hangText="d)">A consumer shall chose a captre scene entry rather than choosing individual captures from multiple entries. This does not mean that an consuming endpoint must render all the captures. What is locally rendered and how is a local decision.</t>
</list></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC2629;
&RFC3552;
&RFC5226;
<reference anchor="I-D.ietf-clue-framework">
<front>
<title>Framework for Telepresence Multi-Streams</title>
<author initials="A" surname="Romanow">
<organization></organization>
</author>
<author initials="M" surname="Duckworth">
<organization></organization>
</author>
<author initials="A" surname="Pepperell">
<organization></organization>
</author>
<author initials="B" surname="Baldino">
<organization></organization>
</author>
<date year="draft-ietf-clue-framework-06 (work in progress)" />
</front>
</reference>
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems).
v06 2010-04-01 TT Changed ipr attribute values to latest ones. Changed date to
year only, to be consistent with the comments. Updated the
IANA guidelines reference from the I-D to the finished RFC. -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:49:01 |