YD T 1496-2006 数字蜂窝移动通信网.移动流媒体业务终端技术要求.pdf

1、YD 中华人民共和国通信行业标准YD.厅14962006数字蜂窝移动通倍网移动流媒体业务终端技术要求。igitalCellular Mobile Telecommunication Network Service Technical Specification for Mobile Streaming Terminal 2006-09-26发布2007-01-01实施中华人民共和国信息产业部发布YD厅14962006目录自次自.”. JI JV图2生!II,犯性引用文件.3 定义和缩赂语.33 I 定义.3 3.2 缩略治”嗣.3 4终端应支持的流媒体业务和功能.4 4.1 业务要求.44.2

2、 功能要求.4 5 流媒体终端总体结构.喇.5 5.1 客户端功能描述. 5 5.2 协议械.”.66 协议.，.6 6.1 会话发起.币6.2 能力交换6 6.3 会话建立和l控制.7 6.4 M肌侃媒体类型现.g 6.5 数据传输.9 6.6 编解码.96.7 SM江场景描述.12 7 文件格式.12 8 数字版权管理.12 9 安全性要求.喃，回回.12 m硬件要求.13 YD!T 1496-2006 n 前言本标准是数字蜂窝移动通信网流媒体业务系列标准之一，该系列标准的名称及结构如下：I.数字蜂窝移动通俗闷移动流媒体业务总技术要在求2“数字蜂窝移动通信网移动流媒体业务服务器技术要求3.

3、数字蜂窝移动通傍网移动流媒体业务终端技术要求4.数字蜂窝移动通信网移动流媒体业务服务器测试方法5.数字蜂窝移动通信网移动流媒体业务终端测试方法随着技术的发展，还将制定后续的相关标准。本标准与数字蜂窝移动通信网移动流媒体业务终端测试方法配态使用。本标准由中国通信标准化协会提出并归口。本标准起草单位：信息产业部电信研究院中国联合通俗有限公词华为技术有限公司中兴通讯股份有限公司本标准主要起草人：杨红梅朱庆辛苦楚晓字杨锦春二E升草草沈灿刘继兴YD.厅1496币2006数字蜂窝移动通倍网移动流媒体业务终端技术要求1 范罔本标准规JE了数字蜂窗移动通信网为实现流媒体业务流媒体终端应支持的业务以及软件和硬件

4、方面的哥哥求，主要包括终端应支持的流媒体业务、流媒体终端总体结构、协议、文件格式、数字版权管理、安全性要求以及硬件要求等内容。本标准适用于以IP分级来承载流媒体成务的数字蜂窝移动通信网络的终端。2规范性引用文件下列义件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，主主随后所有的修改单（不包括勘误的内容）或修订版均不滔用于本标准。然而，鼓励根据首本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其量重新版本运用于本标准。l 町U-TRecommendation H.263一AnnexX (2001): Annex X: Pro创阳andlevels

5、 definition”. 2 U-T Recommendation H.263 -Annex X (03/04）：”AnnexX：阶口创es酬dlevels de伽ition飞3U翩TRecommendation H.264 (2003）：响Advancedvideo coding for generic audiovisual services” l ISO/IEC 14496-10:2003: Infonnation technology - Coding of audio-visual objects - Part 10: Advanced Video C创ing飞4 3GPP TS

6、26.234 V6.2.0 (2004-12): End-to-end tr胡sparentstr明mingservice；阶otocols四dCodecs. 5 3GPP TS 26.245:”Transparent end-to-end packet switched streaming service (PSS); Timed text fo口nat”6 3GPP TS 26.244：叮ransparentend-to-end packet switched streaming service (PSS); 3GPP file fonnat (3GP). 7 3GPP TS 26.401

7、：咱eneralaudio codec audio processing functions；日由ancedaacP!us general audio codec; Gen时aldesiption” 8 3GPP TS 26.410：咱eneralaudio codec audio processing functions; E协anc圳础cPlusgener咀laudio codec; Floating“ point ANSI-C code. 9 3GPP TS 26.411:”General audio c创ecaudio processing functions; Enhanced aa

8、cPlus general audio codec; Ftxed唰pointANSI“ c code”. (10 3GPP TS 26.290:”Extended Af,在RWideband c创ec;Transcoding functions飞 11 3GPP TS 26.304:”ANSI-C code for the Floating静point;Extended AMR Wideband codec. (12 3GPP TS 26.273:”ANSI”C C创efor the Fuc:ed-point; Extended A如仪Widebandcod即飞(13 3GPP2 C.$005

9、0-0 vi.。“3GPP2日leForma臼forMultimedia Services” 14 W3C Candidate Recommendation：咱esourc难。escriptionFramework (RDF) Schema Specification I.。”March2000.YD厅149620062 (15) W3C Working Draft Recommendation:”CC/PP structure and vocabularies”, June 2001 16 WAP UAProf Specification, October 2001. 17 IETF RFC

10、 2326:”Real Time Streaming Protocol （民TSP),Schulzrinne 况，RaoA. and Lanphier R., April 1998. 18 IETF RFC 3267:”Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) Adaptive Mult Rate Wideband (AM比WB)Audio Codecs”, Sjoberg J. et al., June 2002. 19

11、 IETF RFC 3016：吮TPPayload Format for MPEG-4 AudioNisual Str咄咄”，KikuchiY. et al” November 2000. 20 IETF RFC 2429: RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video （日.263），Bormann C. et al., October 1998. 21 lETF RFC 2046: Multipurpose Internet Mail k出nsions(MIME) Part Two: Media Type

12、s”, Freed N. and Borenstein 风，November1996. 22 IETF RFC 2083:”PNG (Portable Networks Graphics) Specification Version I.。”，BoutenT.,etal., March 1997. 23 W3C Recommendation:”Scalable Vector Graphics (SVG) I.I Sp四ifica咀on”，Janu田y2003. 24 IETF RFC 3236：”The坤plication/xhtml刊时MediaType, B冰erM. and Stark

13、P., January 2002. 25 W3C Recommendation: ”Synchronized Multimedia Integra世onh叩1age。如侃2.0）”，August 2001. 26 IETF RFC 1889:”RTP: A Transport Protocol for Real-Time Applications, Schulzrinne H. et 乱，January 1996. 27 IETF RFC 1890：吹WProfile for Audio and Video Conferences with Minimal Control, Schulzrin

14、ne H. et al., Janu缸y1996 28 IETF SID 0006:”User Datagram Protocol, Postel J., August 1980. 29 Scalable Polyphony MIDI Specification Version 1.0, RP-34, MIDI Manufacturers Association, Los Angeles, CA, February 2002. 30 Scalable Polyphony MIDI Device 5-to剖NoteProfile for 3GPP Version 1.0, RP-35, MIDI

15、 Manufacturers Association, Los Angeles, CA, February 2002. 31 Stand时MIDIFiles 1.。”，RP-001,in”四eComplete MIDI 1.0 Detailed Specification, Document Version 96.1 ”, The MIDI ManufacturetAssociation, Los Angeles, CA, USA, February 1996. 32U-T议ecommendationT.81 (1992) I ISO/IEC 10918-1:1993:”Information

16、 t出hnologyDigital compression and coding of continuous-tone still imagesR叫uirementsand guidelines飞33 C-Cube Microsystems: JPEG File Interchange Format, Version 1.02, September 1, 1992 34 W3C Last Call Working Draft:”Scalable Vector Graphics (SVG) 1.2”, October 2004” 35 s切nd盯dECMA-327：也CMAS口ipt3rd Ed

17、ition Compact Profile, June 2001. 36 W AP Forum Specification:”XHTML Mobile 阶ofile，October200 I. YD厅1496-2006S定义和缩略语下列定义和l缩赂i丧适用于本标狱。3.1 2在义连续媒体（continuousmedia）：有内在时间概念的媒体，夜半你液中包指谐音、辛苦额、视锁和时间问步义本（咀medtext ）。j离散媒体（discretemedia）：本身不含时间元家的媒体，在本标准巾是指所有未被定义为连续媒体的媒体，包扫盲宇止图片、文本。设备能力描述（devicecapability de

18、曰：ription）：终端设备能力和或用户选项的描述，包含系列的能力扇傲。设备能力档案（devicecapability profile）：相当于终端设备能力描述。表示描述（presentationdescription）：包含某个淡治中一个或多个媒体流的相关信息，例如编码袋、网络地址以及内容相关倍，息。客户端（client）：使用数字蜂苦苦移动通俗网流媒体业务的客户，可以是具有流媒体功能的终端设备，也可以是流媒体播放器软件。服务器（se凹er）：葱于IETFRTSP/SDP和或HTIP标准的数字躲禽移动通信网流媒体业务的服务糕。场景描述（scened回cription）：对演示的结空间布局与

19、日才闵行为描述，其中还可能包含超链接。3.2缩赂谱3GP 3GPP file format 3GPP文件格式302 3GPP2 file f倒nat3GP凹文件格式AAC Advanc叫AudioCoding 高级音频编码CC/PP Composite Capability I Prefer、neeProfiles 复合能力属己最档案。IFGraphics Interchange Format 隐形交换格式HTh在LHyper Text Markup Language 超文本标记请寄阻TFInternet Engineering Task Force 互联网工程任务组ITU“T Interna

20、tional Telecommunications Union 国际电信联盟Telecommunications JFlF JPEG File Interchange Format JPEG文件交换格式MIDI Musical Instrument Digital Interface 乐器数字接口M队1EMultipmpose Internet M副IExtensions 多用途Ji联网邸仲扩展MMS Multimedia Messaging Service 多媒体消息业务PNG P时tableNetworks Graphics 便携网络图形PSS Packet-switched S町earn

21、ingSenice 分组交换流媒体!ll!.务QCIF Quarter Common Intermediate Format 四分之一公共中问格式RDF Resource Description Framework 资源描述框架RTCP RTP Control Protocol RTP控制协议RTP Real-time Transport Protocol 实时传输协议RTSP Re创羽meStreaming Protocol 实时流媒体协议3 YD!T 1496 2006 SOP Session Description Protocol SMIL Synchronised Multime i

22、ia Integration Language SP-MIDI Scalable Polyphony MIDI SVG Scalable Vector Graphics U A Prof User Agent Profile UTF-8 Unicode Transformation Format (the 8-bit form) W3C WWW Consortium WML Wrreless Markup Language XH1孔1LeXtensible Hyper Text Markup Language 会滔描述协议同步多媒体集成语言词诩级的和弦MIDI可缩放向最阁用户代现档案Unico

23、de转换格式（8位格式）WWW联盟无线标记请寄可扩展超文本标记语言4 终端应支持的流媒体业务和功能4.1 .ill!务要求支持流媒体业务的终端应和流媒体服务部配合让移动用户能够边下载边观餐Ii&昕多种流媒体业务。包括使用静态图像和语音实现的低比特速率新闻流播放、不同比特东和不同质毁的音乐欣赏、1阻辛苦视频剪辑和体育比赛实况等。终端成能支持流媒体点播、流媒体直播、下载播放流媒体等业务类坝。4.2 功能要求( I ）终端的视频播放的商而尺寸1至少为QCIFo(2）支持流媒体业务的终端应同时交捋WAP刷刷SI多媒体邮件业务。( 3) 用户下裁完某个流媒体片段之后，)iiz能提示用户是否需要立即播放。

24、(4）下载的媒体文件可以被其他程序（如WAP、h仙1S多媒体邮件）访问和使用；文件的存储空间成该与其他媒体文件的空间共事。(5）流媒体终端成交待常见的播放、回放、暂停、停止、前进、后退、音釜控制和静音等操作。(6）播放器需要能够查看收件箱占用空间的大小，空间的占有幕。( 7)流媒体终端)iiz支持用户直接输入议：TSPU议La(8）流媒体终端成具有外部察件的处现功能，l!P：在流媒体业务进行的过程中，者发生外部事件如来也、短消息到达等，终端应能正确处理，以保证正常通信功能的开烧。4 5流媒体终揣总体结构5.1 客户端功能描述YD.斤1496-2006流媒体终端$.包含的交接功能单元如阁l所示，

25、.:E姿包括饺制、场f盖捎i杰、媒体解码器等。!ii校制相关的单元是能力交换、会话建立和会说控制。阁1寝户端功能单元会话建立是指自浏览器或直接在终端用户界因输入URL地址发起PSS会话。能力交换可以根据不同的终端能力选择l莲配媒体流。会话控制处理直在个蝶体流的建立，这个媒体流是在一个流媒体客户端与一个或多个流媒体服务.ff间传送的。会话校制也允许用户控制单个媒体流。另外，会话控制还可以包含流媒体播放控制功能，如开始、暂停、快进和停止。场景描述自穷问结构和媒体演示中不同媒体间的时间关系描述组成。前者纷出屏幕上不同媒体成份YD厅14962006 的布阂，后者控制不同媒体的同步。媒体解码器包J古语音

26、、音频、合成音频、文本、l司tl7文本、d景图形、图像以及视频嫁体的解码。5.2 协议梳草草户端的协议校以及更详细的蒸于分级的网络接口捕述如网2所示。，”h啊M能力交换场景描述视频司提耶描述音频静态网f且能力交换涵盖i!L阁阁彤，但撤图形表t币描i主文本文本，同步文本合成音频Payload formats 自ITPRTSP RTP UDP TCP UDP IP 一圈2流媒体毒害娟的协议钱(I) IfITP厅CP/IP传输协议HTTP协议用于流媒体发现和视频下载。通过HP可以获得流媒体的连接URL，也可以通过日？获得SDP文件。同时，日？协议可以实现媒体下载业务。( 2) RTSP.厅CPIUD

27、P/IP实时流媒体协议RTSP协议是用于控制流媒体过程的协议，包括流媒体的建立、播放、暂停、快进快退、停止等功能。RTSP协议可以支持的方法有DESCRIBE,SETUP, PLAY, PAUSE，阻。眼见CT和冗ARDOWN等。(3）民.TP/RTCP实时传输协议民TP主要用于传输流媒体巾的视频、吉普频手口语音等媒体内容。l!3应用程序开始一个民TP会话时将使用两个端曰：一个给阳？，一个给R于PoRTP本身并不能为按顺序传送数据包提供可霖的传送机制，也不提供流量控制或拥塞控制，它依靠RTCPm供这些服务。(4) RTCP实时传输控制协议RTP主要害F日子服务器和客户端之间的流盛控制和1拥草草

28、控制。在RTP会15期间，各参与者周期性地传送RTCP包，RTCP中包含已发送的数据包的数慧、丢失的数据包的数援等统计信息，服务器可以利用这些信息、动态改变传输速率。RTP和RTCP配合使用，能以有效的反馈手0簸小的开销使传输效率最佳化。6协议6.1 会话发起客户端应泵少能支持以下方式之一来发想会话：SM庇，SDP，明文RTSPURLo除r:stp：外，客户端还应支持URL,以便由自le:/I（用于本地存储的文件）和h即：II（用于通过IfITP传送的演示描述或场景描述）开始的起始会话协议有效。客户端能够以多种方式获取URL，本标准不作限定。例如，将URL嵌入到HTML或W皿页中，这样，文挤H

29、？协议的浏览器能够下载起始会话描述，并将内容传递到客户端用于将来的处理。6.2 能力交换6.2.1 概述6 YD斤14962006为了让流媒体服务将根搅多种类攘的终端客户端设备交待不问的内容，也为了我不问版本的PSS架构均占是供服务，客户端应交待能力交换，向服务将t提供终端的流媒体能力。6.2.2设备能力档案（Profile）结构设备能力梢9在经个RDF文档（参见”W3CCandidate Recommendation: Resource Description Framework (RDF) Schema Specification 1.0 March 2000），其主商构符合CC/PP帧结

30、构（参见W3CWorking Draft Recommendation：C/PP structure and vocabularies“June 2001）非UCC/PP应用UAProf（参Jii1WAPUAProf Speci白cation,Octobe町2001“）。用革毒性来搅述设备能力和参数。阳F格式模式中定义了一生且扇1余名称、允许的参数僚和CC/P刊词汇编成的滔义。PSS沿用UAProf词汇，也JE.义了部分PSS的专有词汇。词汇丰各式巾JE.义了属性的谱法，f均在i蚕义上有扩展。PSS设备能力档案处UAPro俐或PSS特殊格式的个实例，问时应按照CC/PP规范”structure

31、础dvocabulari郎”（参见W3CWorking Dra且Recommendation:CC/PP structure and vocabularies, June 2001 ）的规则组织能力档案信息。能力档案格式也应按照UAProf（参见”WAPUAProf Speci且cation,October 2001”）的第7、7.1、7.3、7.4节中定义的规则组织。6.2.3 PSS扇性术语有关PSS扩艇的设备能力档案术语的描述参见3GPPTS26刀4o6.2.4 PSS模式（Schema）词汇的扩展所有对档案模式（profileschema）的扩版囱切APUAProf Specifica

32、tion, October 2001啪7.7条定义的规则进行管现。6.2.5 客户端和服务键之间的档案（PofileJ信息的错令能力交换特性为TiJ逃。如果客户端支持能力交换，那么它Iii.遵循WAP2.0 UAProf规范。档案情息通过K盯？和议TSP传送。 RTSP：客户端在DESC民IBE消息中发送档案信息。 HV：客户端在GET请求的返因消息中附加档袋信息。这样，HTfP服务器可以传送一个优选的SDP给客户端。6.2.6流媒体服务器和设备档案服务翻之间档案（profile）的传送设备能力档案存储在设备梢案服务器上，通过URL引用。终端在上报客户端支持能力的消息中，可以只上报该URL。有

33、关流媒体服务器和设备档案服务器之间终端梢案信息的传送不在本标准定义的范阁内。6.3会话建立和接制6.3.1 概述使用RTP用DP盼的连续媒体流需要有会话控制协议来建立和控制单个的媒体流。对于离散媒体（图像和文本），矢量图像，同步文本和合成的资频，使用HTTP厅CP/IP方式，在这种情况下不需要一个单独的会话建立和控制协议，因为它已经存在于HTfP之中。本条描述连续媒体语膏、音频和视频的会话建立和控制。6.3.2 RTSP 盯SPJii.用于会话建立利会话控制。终端Iii.遵循IETF民FC2326 （参见lETFRFC 2326：”民ea!Time Stre删ngProtocol (RTS酌”

34、）的附加中的规则，该规则翩翩务的最小实现。此外，终端应支持发送DESCRIBE f悟，鼠，并对应答激行解释。7 YDfT 1496-2006 6.3.3 SDP 6.3.3.1 概述SOP给出了媒体的描述仿息，包fli帧率、自到1敦大小等信息。SOP作为服务苦苦传i没给客户端的表示描述格式。客户端应能够解释SDP语法。3GPP TS 26.234规范要求在一个SDP文件中必须包含某些民域。此外，终端应能够解释下列域：a巴control.;一飞range：”，一”a=rmap：”；一、黑伽1：以下阂险作为1iT选：”a=X-predecbufsize:” 该域按字11给出了锁解码缓冲区的大小。”

35、a=X切itpredecbufperiod:”该域纷出了后解码缓冲周期。该德是一个90kHz时钟的时钟点滴（ticks）。”a=X-d四b泸era悟：仰akdecoding byte rate” 该城给出峰僚解码字节惑，通过附录G验证流的兼容性。该假以每秒钟字节数的形式纷出。下列媒体应SOP域的定义用于SDP:、framesize: -” 该城给出了日.263流的最大视频帧的尺寸。客户端需要SDP中的帧尺寸城以便正确地分配帧缓冲存储器。对于阳EG-4视频流，帧尺寸应该从SDP中的”config”信息中提取。对于日.263流，PSS服务器应在SDP中为每一个流在媒体层包含”a=fram阳四”坝，

36、并且如果该城存在，客户端应解释该域。客户端应能接收没有该属性的SDP描述。如果这个属性存在，帧尺寸参数应IE好匹配视频流中的最大帧尺寸。宽和裔的值应用像絮表示。6.4 MIME媒体类型对于连续媒体（语音、音频和视频），成使用下列M肌伍媒体类型：AMR-NB语苦苦编解码器（参见IBTFRF3267：”Real厅imeTransport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) Adaptive Multi” Rate Wideband （州仪矶IB)AudioCo

37、decs”); AMR”WB谐音编解码器（参见IBTF盯3267：”Real币meTransport Protocol O主JP)Payload Format 础dFile Storage Format for the Adaptive Multi-Rat（AMR)Adap咀veMulti”Rate Wideband (AMR-WB) Audio Codecs); Enhan四daacPlus和MPEG4AACf/i频编解码的M岛包媒体类型（参见IBTFRF3016：”RTP Payload Format for MPEG-4 AudioNisual Streams ); MPEG4视频编解码

38、（参见IETFRFC 3016:”RTP Payload Format for MPEG-4 Audio/Visual Streams”); 8 YD厅1496-2006日，263视频编解码器（要害，见IETFRFC 2429:”RTP Payload Format for the 1998 Version of町U翩TRec. H.263 Video (II.263+)”); SP MIDI的MIME媒体类型。用于JPEG,GIF, PNG, SP翩MIDI,SVG，同步文本和XHML的M酌伍媒体类型既能用于日口？中的，。Content-type”域，也能用于SMIL2.0的”type瑞性。

39、下列的M阳E媒体类骂!iii:被用于这些媒体：JPEG （参见IETF阳c2046:”Multipurpose Internet Mail Extensions (M肌但）Part Two: Media 乃pes); GIF （参见IETFRFC 2046：”Mui咀purposeInternet Mail Extensions (MIME) Part Two: Media Types”); PNG （参见IE1节即C2083: PNG (Portable Networks Graphics) Speci自cationVersion 1.。”）； SP“ MIDI SVG （参见W3CReco

40、mmendation:”Scalable Vector Graphics (SVG) 1.1 Sp四ification); x町阳在L（参见IE1于即3236:The application/xhtml+xml Media Type”) 饥medtext0 用于SMIL文件的M肌媒体类型应根据W3CRecommendation SMIL 2.0 （参见W3CRecommendation: Synchronized Multimedia Integratio咀Language(SMIL 2.0）”）而定，用于SDP的MIME媒体类现应根据IETF盯c3016而定。6.5敛据传输6.5.1基于IP

41、的网络接口媒体流和控制流的承载协议均为IP协议。6.5.2媒体流的传输寨子UDP/IP的ATP协议IETF民FC1889（参见IETFRFC 1889：叹TP:A Transport Protocol for Real-TlillAppli阳lions”）和IETFRFC 1890 ( IETF RFC 1890:”RTP Pro !le for Audio and Video Con也renceswith Min凶alControl”）提供了基于UDP传输实时数据或者流数据的方法（参见IETFSTD 0006：”Us町Data伊mProt凶。1”）。编码厉的媒体信息利用嫁体特定的RTP有效负

42、载的格式封装为RTP报文。盯？有效负载的格式由IETF定义。RTP还提供r名为民：TCP的协议（参见IETFRFC 1889中的第6节）来反馈传输的质簸。为计算民TCP的传输问闹，要使用脏TF议F1889中的附录A几6.5.3基于TCP/IP的HTIP协议IETFTCP提供了IP网络上的可靠数据传输，但没有时延保障。它是发送场景描述、文本、t蓝图图形和静态图片的首选方式。6.5.4 RTSP的传输终端支持的盯SP传输应与RFC2326 （参见IETFRFC23篇：”R幽1咀meStr出削ngProt时咀I(RTSP)”) 致。6编解码移动流媒体终端所交铃的媒体内容的编解码格式与业务类型无关，即元论是点播、直播，还是下载播放，这些格式都是可用的。移动流媒体终端支持的编码类激如下，其叶3音频和视频的编解码类型可以任意组合。9 YD厅1496-20066.6.1 音频对于UMTS系统，应支衍AMR-N日，还应支捋以下青颇丰各式的种或阅种： Enhanced aacPlus，依据3GPPTS 26.401、3GPPTS26.410、3GPPTS26刷411; Extended AMR畸晒，依据3GPPTS 26.290、3GPPTS 26.304、3GPPTS26.2730 Enhanced aa