One document matched: draft-deng-rtcweb-codecapi-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- 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 RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.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="yes" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-deng-rtcweb-codecapi-00.txt" ipr="trust200902">
<!-- ***** 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>Proposal for reusing local codec APIs on mobile devices
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Lingli Deng" initials='L.L.'
surname="Deng">
<organization>China Mobile</organization>
<address>
<email> denglingli@chinamobile.com</email>
</address>
</author>
<author fullname="Lingfei Ni" initials='L.'
surname="Ni">
<organization>China Mobile</organization>
<address>
<email>nilingfei@chinamobile.com </email>
</address>
</author>
<author fullname="Qing Yu" initials='Q.'
surname="Yu">
<organization>China Mobile</organization>
<address>
<email>yuqing@chinamobile.com </email>
</address>
</author>
<date day="8" month="July" year="2013" />
<!-- Meta-data Declarations -->
<area></area>
<workgroup>Network Working Group</workgroup>
<keyword></keyword>
<abstract>
<t> This document proposes the browser to make use of local codec APIs, if available on a mobile device, and notifies RTCWEB applications to allow for better tuning between device capability and media quality.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>It is expected that by including the built-in real-time communication capabilities into a general purpose browser, the development and integration of person-to-person communication experience into a web page, without pre-installation of any additional software.</t>
<t>There has been extensive discussion on the MTI video codec for RTCWEB browsers for quite a period of time. Whereas so far the discussion has mainly focused on evaluating one against another based on merits as well as IPR issues. </t>
</section>
<section title="Discussion">
<section title="Built-in media capabilities in mobile devices">
<t>Unlike general purpose personal computers, smart phones have built-in support for audio/video encoding/decoding functionalities, as their traditional role is to serve as a phone. </t>
<t>Considering other types of mobile devices, like Wifi-only tablets, users are increasingly expect that they also provide real-time media channels in one way or another. For instance, watching streaming clips from a web page, or chatting with family members and friends through VoIP applications.</t>
<t>In all, it is expected that a mobile device provides some sort of built-in media processing capabilities in the first place. For instance, Android system provides various media encoding/decoding support [android-codec-support]. IOS platforms also supply hardware-accelerated codec APIs for built-in codecs [apple-codec-support].</t>
</section>
<section title="MTI codecs for mobile devices?">
<t>We made the following observations on this point for mobile devices:
<list style="symbols">
<t>A couple of MTI codecs may not be sufficient for a general purpose browser targeting the mobile users. </t>
</list>
</t>
<t>On the one hand, a user's expected/perceived media quality of a real-time communication applications, which is largely dependent on the device in hand and the type of service they are using, is hardly possible to be covered by a handful of MTI codecs. </t>
<t>To begin with, as different devices vary in size of screen, hence a HD video stream, which would be appreciated for a tablet user, could turn out to be a waste of resources for a smaller-screened smart phone. </t>
<t>Furthermore, considering the case of interworking, it is almost always better to use the same choice of codec as the other end than to choose another one and to do trans-coding in between.</t>
<t>
<list style="symbols">
<t>A universal package of codecs is not cost-effective for mobile browsers.</t>
</list>
</t>
<t>Despite the rapid increase in processing power and wireless bandwidth, portal mobile devices are bonded by short-lived battery power and physical size, it would not be wise for a mobile browser to include the bunch of all the potentially needed codecs. Since this would consume much more resources and expand the installing package as well. What's worse, it could mean extra expense for the browser vender to include each patented codec algorithm.</t>
</section>
</section>
<section title="Proposal">
<t>In summary, we believe it could be desirable for the browser to make use of local media support provided by the end device system into the candidate pool for various web applications to choose for their specific RTCWEB usage cases and differential quality expectations accordingly. Because reusing the local codec support has the following advantages:
<list style="symbols">
<t>It reduces the implementation complexity and potential patent cost for general purpose browsers.</t>
<t>It would eliminate the risk of degrading user experience when compared with other real-time communication applications using the same local facility.</t>
</list>
</t>
<t>Specifically, the indicated requirements are two-folded: </t>
<section title="Function Requirement for Browser">
<t>Firstly, a RTCWEB-compatible browser MAY make use of codec APIs supported by a mobile device locally be default and include them into SDP offer/answer exchange with the other end.</t>
</section>
<section title="API Requirements for Browser">
<t>Moreover, it SHOULD be possible for the JS to be able to distinguish the locally supported codecs from the other browser-bounded ones, and be allowed to make proper choices based on the specific communicating scenario in question.</t>
</section>
</section>
<section title="Security Considerations">
<t>TBA</t>
</section>
<section title="IANA Considerations">
<t>None.</t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
</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;
&RFC2234;
</references>
<references title="Informative References">
<!-- A reference written by by an organization not a person. -->
<reference anchor="android-codec-support">
<front>
<title>http://developer.android.com/guide/appendix/media-formats.html#core</title>
<author initials="" surname="">
<organization></organization>
</author>
<date month="" year="" />
</front>
</reference>
<reference anchor="apple-codec-support">
<front>
<title>https://developer.apple.com/library/ios/#documentation/AudioVideo/Conceptual/AVFoundationPG/Articles/00_Introduction.html#//apple_ref/doc/uid/TP40010188</title>
<author initials="" surname="">
<organization></organization>
</author>
<date month="" year="" />
</front>
</reference>
</references>
</back>
<!-- Here we use entities that we defined at the beginning. -->
<!-- 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). -->
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:05:04 |