| Network Working Group | L.L. Deng |
| Internet-Draft | L. Ni |
| Intended status: Informational | Q. Yu |
| Expires: January 08, 2014 | China Mobile |
| July 07, 2013 |
Proposal for reusing local codec APIs on mobile devices
draft-deng-rtcweb-codecapi-00.txt
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 08, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
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.
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.
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.
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].
We made the following observations on this point for mobile devices:
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.
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.
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.
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.
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:
Specifically, the indicated requirements are two-folded:
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.
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.
TBA
None.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC2234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. |
| [android-codec-support] | , , "http://developer.android.com/guide/appendix/media-formats.html#core", . |
| [apple-codec-support] | , , "https://developer.apple.com/library/ios/#documentation/AudioVideo/Conceptual/AVFoundationPG/Articles/00_Introduction.html#//apple_ref/doc/uid/TP40010188", . |