Omtp Codecs 1 0, Release 1
Total Page:16
File Type:pdf, Size:1020Kb
OMTP CODECS DEFINITION AND REQUIREMENTS This document contains information that is confidential and proprietary to OMTP Limited. The information may not be used, disclosed or reproduced without the prior written authorisation of OMTP Limited, and those so authorised may only use this information for the purpose consistent with the authorisation. VERSION: OMTP CODECS 1_0, RELEASE 1 STATUS: SUBJECT TO BE - APPROVED BY BOARD 21 JULY 2005 DATE OF LAST EDIT: 6 JULY 2005 OWNER: P4: HARDWARE REQUIREMENTS AND DE- FRAGMENTATION OMTP CODECS CONTENTS 1 INTRODUCTION ............................................................................4 1.1 DOCUMENT PURPOSE ..........................................................................4 1.2 INTENDED AUDIENCE ............................................................................5 2 DEFINITION OF TERMS .................................................................7 2.1 CONVENTIONS .....................................................................................7 3 OMTP CODEC PROFILES ............................................................8 3.1 AUDIO DECODE....................................................................................8 3.2 AUDIO ENCODE....................................................................................9 3.3 VIDEO DECODE....................................................................................9 3.4 VIDEO ENCODE....................................................................................9 3.5 IMAGE DECODE..................................................................................10 3.6 IMAGE ENCODE..................................................................................10 3.7 VECTOR DECODE...............................................................................10 4 FUTURE VERSIONS ....................................................................11 5 APPENDIX.................................................................................12 5.1 USE CASES AND CODECS MAPPING.....................................................13 6 ABBREVIATIONS ........................................................................14 7 REFERENCED DOCUMENTS ........................................................15 © 2005 OMTP Ltd. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written permission from OMTP Ltd. Page 2 of 16 OMTP CODECS The information contained in this document represents the current view held by OMTP Ltd. on the issues discussed as of the date of publication. This document is provided “as is” with no warranties whatsoever including any warranty of merchantability, non-infringement, or fitness for any particular purpose. All liability (including liability for infringement of any property rights) relating to the use of information in this document is disclaimed. No license, express or implied, to any intellectual property rights are granted herein. This document is distributed for informational purposes only and is subject to change without notice. Readers should not design products based on this document. "OMTP" is a registered trademark. Other product or company names mentioned herein may be the trademarks of their respective owners. © 2005 OMTP Ltd. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written permission from OMTP Ltd. Page 3 of 16 OMTP CODECS 1 INTRODUCTION This document represents the de-fragmentation and requirements developed for codecs within OMTP. It defines recommended classes of codecs for mobile terminals. Further classes will be added in future versions of the documents with the availability of the on-going technologies. The reason for defining these classes is the large variety of codecs and characteristics available on mobile terminals, which results in the following potential issues: 1. The user experience of ‘look & feel’ is affected. 2. By making application developers and content providers address all the codecs paradigms, operational costs are increased. 3. The perceived quality of video services is heavily influenced by codec characteristics. 4. Business opportunities depend on bandwidth utilisation which, in turn, is determined by codec characteristics. OMTP has addressed the codec de-fragmentation issue in order to: 1. Reduce the operational costs. 2. Improve user perception of the video services provided. 3. Make the specification of requirements for mobile terminals easier and more precise. 4. Reduce the NRE cost due to the re-engineering of applications and contents to support new terminals. See 3 for some example cases. 1.1 DOCUMENT PURPOSE This document has the general objective of helping to define the terminal requirements and allowing development and deployment of new services, as well as de-fragmenting the codecs capabilities onboard of terminals. Its scope is to guarantee consistency, quality and performance of video and audio services by: • Definition of the audio and video capability of mobile terminals, in terms of the coding techniques supported. • Ensuring the codec features suit both application and baseband processor capabilities. © 2005 OMTP Ltd. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written permission from OMTP Ltd. Page 4 of 16 OMTP CODECS The document focuses on: • Voice codecs • Audio codecs • Video codecs • Image codecs In particular, the document concurs with the OMTP Main Objectives: Facilitate Implementation of Open Mobile Terminal Platforms • Work as appropriate to drive the development of specific mobile terminal platforms to meet OMTP requirements. Influence the standardisation of relevant platforms. Work with vendors of proprietary platforms to adopt OMTP requirements and/or resulting standards. Understand the implementation roadmap and ensure conformance to OMTP requirements. In particular, it addresses the hardware enablers through the production chain to facilitate OMTP terminal development. Define De-fragmentation Guidelines • De-fragmentation guidelines reduce costs (for both operators and manufacturers) and increase consistency by defining: Hardware component parameters. Software component parameters. Performance guidelines and benchmarks. 1.2 INTENDED AUDIENCE The document is intended to be used as reference in: • Terminal requirements definition by operators. • Platform and terminal characteristics definition. • To refer to supported codecs in the definition of mobile terminal performance. Some examples of usage follow: © 2005 OMTP Ltd. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written permission from OMTP Ltd. Page 5 of 16 OMTP CODECS Within terminal requirements: “Codecs set: capable of supporting codecs defined in OMTP CDV1 (OMTP CODECS v1.0)”. Within hardware requirements for an application: “The application requires codecs defined in OMTP CDV1, OMTP CDA1 and OMTP CDI0 (OMTP CODECS v1.0) to be able to run”. Within content database: “The video is formatted to be viewed with a terminal capable of supporting codecs defined in OMTP CDV1 (OMTP CODECS v1.0)”. Within platform description: “The platform can support codecs defined in OMTP CDA1 (OMTP CODECS v1.0)”. © 2005 OMTP Ltd. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written permission from OMTP Ltd. Page 6 of 16 OMTP CODECS 2 DEFINITION OF TERMS This chapter contains the definition of terms used in this document. 2.1 CONVENTIONS The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119] (see [1] in 7). MUST: This word, or the terms "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the specification. MUST NOT: This phrase, or the phrase "SHALL NOT", means that the definition is an absolute prohibition of the specification. SHOULD: This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" means that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label. MAY: This word, or the adjective "OPTIONAL", means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides). © 2005 OMTP Ltd. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written permission