GY/T 304-2016
基本信息
标准号:
GY/T 304-2016
中文名称:高性能流化音频在IP网络上的互操作性规范
标准类别:广播电影电视行业标准(GY)
标准状态:现行
出版语种:简体中文
下载格式:.zip .pdf
下载大小:5952229
相关标签:
高性能
音频
网络
规范
标准分类号
关联标准
出版信息
相关单位信息
标准简介
GY/T 304-2016.High-performance streaming audio-over-IP interoperability.
1范围
GY/T 304规定了在IP网络上传输全频带和低噪声的高性能音频的互操作模式。
GY/T 304适用于广播、音乐制作和影视后期制作设备间信号的交换,也可用于商业音频应用,如固定和流动的现场扩声.
2规范性引用文件
下列文件对于本标准的应用是必不可少的。凡是注日期的引用文件,仅所注8期的版本适用于本标准。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本标准。
GB/T 25931- -2010网络测量和控制 系统的精确时钟同步协议(IEC 61588- 2009, IDT)
IETF RFC 768用户 数据报协议(User Datagram Protocol)
IETF RFC 791互联网 协议(Internet Protocol)
IETF RFC 112 IP组播的主机扩 展(Host Extensions for IP Multicasting)
IETF RFC 2236互联网组管理协议, 第二版( Internet Group Management Protocol, Version
2)
IETF RFC 2474
IPv4和IPv6包头中的区分服务字段(DS字段)的定义(Definition of the .
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers)
IETF RFC 2616超文本 传输协议-HTTP/1.1 (Hypertext Transfer Protocol - HTTP/1. 1)
IETF RFC 2974会话公告协议(Session Announcement Protocol )
IETF RFC 319012位DAT 音频和20位、24位线性采样音频的RTP有效载荷格式(RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio)
IETF RFC 3261 SIP: 会话发起协议(SIP:Session Initiation Protocol )
IETF RFC 3264使用会话描述协议(SDP) 实现会话提议/应答的模型(An 0ffer/Answer Model with the Session Descript ion Protocol (SDP) )
IETF RFC 3376互联网组管理 协议,第三版(Internet Group Management Protocol, Version
3)
IETF RFC 3550 RTP: 实时传输协议(RTP: A Transport Protocol for Real-Time Applications
IETF RFC 3551使 用最小控制的音视频会议RTP类别(RTP Profile for Audio and Video Conferences with Minimal Control)
IETF RFC 4566会话描述协议(Session Descript ion Protocol)
IETF RFC 7273 RTP时钟源信令 (RTP Clock Source Signalling)
AES5- 2008 脉冲编码调制采用的优先采样 频率(AES recommended practice for professional digital audio- Preferred sampling frequencies for applications employing pulse- code modulation)
AES11- -2009(R2014)演播室 数字音频系统同步(AES recommended practice for digital audio engineering一-Synchronization of digital audio equipment in studio operat ions)
EBU Tech 3326音频在 IP网络上的互操作要求(Audio contribut ion over IP-Requirements for Interoperability)
标准内容
中华人民共和国广播电影电视行业标准GY/T304——2016
高性能流化音频在IP网络上的bZxz.net
互操作性规范
High-performance streaming audio-over-IP interoperability2017-01-04发布
国家新闻出版广电总局
2017-01-04实施
规范性引用文件
术语、定义和缩略语
媒体时钟
编码与成流,
会话描述
发现服务
10连接管理
附录A(规范性附录)
附录B(资料性附录)
附录C(资料性附录)
附录D(资料性附录)
附录E(资料性附录)
参考文献
媒体类别:
TEEE802.1AS时钟域接口
网络QoS配置建议
AVR网络传输
发现系统..
GY/T304—2016
GY/T304—2016
本标准按照GB/T1.1一2009给出的规则起草。请注意本标准的某些内容可能涉及专利。本标准的发布机构不承担识别这些专利的责任。本标准由全国广播电影电视标准化技术委员会(SAC/TC239)归口。本标准起草单位:中央人民广播电台、中央电视台、国家新闻出版广电总局广播科学研究院、国家新闻出版广电总局广播电视规划院、北京英夫美迪科技股份有限公司、苏州市福川科技有限公司、北京众和传新科技有限公司、杭州联汇科技股份有限公司、上海佰贝科技发展有限公司。本标准主要起草人:钱岳林、朱峰、罗攀、潘宇、张磊、王兰岚、庞超、张伟、邓向冬、韦安明、何晶、董晓坡、陈武、陈沁、唐卫平、练文杰。1I
GY/T304—2016
高性能媒体网络支持以低延退(小于10ms)传输专业质量的音频信号(采用线性PCM编码,采样率不低于44.1kHz,量化精度不低于16位),并适用于现场扩声。局域网及企业级网络的性能都可以满足作为高性能媒体网络的要求,但广域网或公共互联网的性能通常无法满足要求。尽管截至本标准颁布前出现的使用各种专有和标准协议的此类媒体网络都基于TP协议,但它们之间无法互操作。
本标准是参照AFS67—2015《High-performancestreamingaudio-over-IPinteroperahility》编制的。
本标准提出了高性能媒体网络互操作性的具体规定。本标准重点规定如何使用现有的协议来创建可互操作的系统。基于这一点,并未开发其他新的协议。III
1范围
高性能流化音频在IP网络上的互操作性规范本标准规定了在IP网络上传输全频带和低噪声的高性能音频的互操作模式。GY/T304—2016
本标准适用于广播、音乐制作和影视后期制作设备间信号的交换,也可用于商业音频应用,如固定和流动的现场扩声。
2规范性引用文件
下列文件对于本标准的应用是必不可少的。凡是注日期的引用文件,仅所注日期的版本适用于本标准。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本标准。GB/T25931—2010网络测量和控制系统的精确时钟同步协议(IEC61588—2009,IDT)TETFRFC768用户数据报协议(UserDatagramProtocol)IETFRFC79l互联网协议(InternetProtocol)IETFRFC1112IP组搭的主机扩展(HastExtensionsforIPMulticasting)IETFRFC2236互联网组管理协议,第二版(InternetGroupManagementProtocol,Version2)
IETFRFC2474IPv4和IPv6包头中的区分服务字段(DS字段)的定义(DerinitionoftheDifferentiated Services Field(DS Field)in the IPv4 and IPv6 Headers)IETFRFC2616超文本传输协议-HTTP/1.1(HypertextTransferProtocol-HTTP/1.1)IETFRF2974会话公告协议(SessionAnnouncementProtocol)TETFRFC319012位DAT音频和20位、24位线性采样音频的RTP有效载荷格式(RTPPayloadFormatfor 12-bit DAT Audio and 20-and 24-bit Linear Sampled Audio)TETFRFC3261
StP:会话发起协议(SiP:SessionInitiationProtocol)IETFRFC3264
使用会话摧述协议(SDP)实现会话提议/应答的模型(AnOffer/AnswerModelwiththe SessionDescription Protocol(SDP))IETFRFC3376互联网组管理协议,第三版(InternetGroupManagementProtocol,Version3)
RTP:实时传输协议(RTP:ATransportProtocolforReal-TimeApplications)IETFRFC3550
IETFRFC3551使用最小控制的音视频会议RTP类别(RTPProfileforAudioandVideoConferenceswithMinimal Control)IETFRFC4566会话描述协议(SessianDescriptionProtocol)IETFRFC7273RTP时钟源信令(RTPClockSourceSignalling)AES5—2008脉冲编码调制采用的优先采样频率(AESrecommendedpracticeforprofessionaldigital audioPreferred sampling frequencies for applications employing pulse-codemodulation)
AES11—2009(R2014)演播室数字音频系统同步(AESrccommcndcdpracticcfordigitalaudioengineeringSynchronization of digital audio equipment in studio operations)EBUTech3326音频在IP网络上的互操作要求(AudiocontributionoverTP-RequircmentsforInteroperability)
GY/T304—2016
IEEE15882002网络测量和控制系统的精确时钟同步协议(IEEEStandardforaPrecisionClock Sychronization Protocol for Networked Measurement and Control Systems)IEEE802.1AS一2011桥接局域网中时间敏感应用的定时与同步(TimingandSynchronizationfor Time-Sensitive Applications in Bridged Local Area Networks)IEEE802.1Q—2011媒体接入控制桥和虚拟桥局域网(MediaAccessContro1(MAC)BridgesandVirtual Bridged Local Area Networks)3术语、定义和缩略语
3.1术语和定义
下列术语和定义适用于本标准。3.1.1
精确时间协议precisiontimeprotocol;PTP由IEEE1588—2002、GB/T25931—2010和IEEE802.1AS—2011定义的通用时钟分发协议。3.1.2
边界时钟boundaryclock
在一个域中具有多个精确时间协议(PTP)端口,并维护该域中所用时标的时钟。它可作为时间源,即为主时钟;也可与另一个时钟同步,即为从时钟。[GB/T25931—2010,定义3.1.3]3.1.3
数字音频参考信号digital audio reference signal;DARsAES11一2009(R2014)中定义的音频时钟信号。3.1.4
汇入源contributingsource;cSRC为RTP混合器生成组合流起到贡献作用的RTP流输入源。3.1.5
区分服务differentiated services对IP网络流量分级并提供不同QoS保障的系统,3.1.6
区分服务代码点differentiated services codepoint;DscP位于IP包头中用于分级的一个6位字段,是区分服务架构中的一部分。3. 1. 7
64位扩展的唯一标识符64 bit extended unique identifier;Eul-64符。
由一个24位或36位的公司注册标识符和一个公司唯一设备标识符组合构成的64位全球唯一标识3.1.8
最高级时钟grandmaster
GY/T304—2016
通过PTP进行时钟分发所需的同步主时钟源。最高级时钟是用64位扩展的唯一标识符(EUI-64)标识的一种网络设备。
最高级时钟标识符grandmasteridentifier;GMID种EUI-64唯标识符,用于标识为同步域提供服务的最高级时钟,在GB/T25931一2010和IEEE802.1AS—2011同步标准中规定。3.1.10
互联网组管理协议
internet group managementprotocal;IGMP主机用来向IPv4路由器报告其组播组成员的通信协议,3.1.11
链路偏移量linkoffset
媒体消耗在网络、发送器的缓存和接收器的缓存中的总时间3.1.12
媒体时钟mediaclock
发送器用于采样和接收器用于播放数字媒体流的时钟。音频流的媒体时钟以音频样值数标注。3.1.13
媒体包mediapacket
媒体流的一部分,承载媒体数据的数据包。每个媒体包包含一个或多个音频通道的一个或多个样值。
最大传输单元maximumtransmissionunit;MTu特定数据链接中能传输的最大IP数据包大小,以字节为单位。以太网数据链路的MTU为1500字节。3.1.15
网络时钟networkclock
由第4章定义的网络同步机制提供的时间,以秒为单位。3.1.16
开放式系统互联模型
opensystemsinterconnectionmodel;oslmode以抽象层的方式描述和规范了通信系统的功能。3.1.17
网络层networklayer
oSImode1的第3层,负责将可变长度数据序列从源转发和路由到日的地。3.1.18
包时间packettime
媒体包中的媒体数据的实际持续时长。3
GY/T304—2016
服务质量qualityof service;Qos描述依据性能要求,在网络中对流量分级、标记和传输的系统。3.1.20
接收器receiver
一种可以从网络接收媒体流的网络设备。3.1.21
请求注释request for comment;RFC由TETF发布的、与Tnternet及Tnterret互联系统的操作相关的规范文档,以编号作为索引。3.1.22
实时传输协议real-timetransportprotocol;RTP一种由RFC3550定义并为应用通过UDP/IP网络构建、标记和传输媒体数据包的协议。3.1.23
实时传输控制协议real-time transpart controlprotacol:RTcP实时传输协议(RTP)的伴生协议,为RTP媒体数据包提供统计分析和控制信息。3.1.24
RTP时钟RTPclock
在包含流数据的RTP包中携带的时间戳。每个流都有自己的RTP时钟。3.1.25
RTP会话 RTP session
和发送器与接收器之间的、基丁RTP协议的媒体连接。RTP会话可以是单播或组播形式。3.1.26
RTP流RTP stream
由已规定的时间间隔发送的媒体数据组成的RTP包串。一个流可以包含多个通道。每个RTP会话可以由多个媒体流构成。
音频流audiostream
媒体数据为音频的RTP流。
会话描述协议sessiondescriptionprotocol;SDp一种用于描述RTP会话和操作属性的格式,包括网络寻址、编码格式和其他元数据属性。3.1.29
发送器sender
一种可以将媒体流发送到网络上的网络设备。4
SIPURI
GY/T304-—2016
种在SIP协议中用于识别用户代理URI的字段。SIPURI采用sip:@或sips:@的描述形式,见10.2.1。3.1.31
从时钟slave clock
-种使用精确时问协议(PTP)与主时钟(即时钟提供者)保持同步的时钟。从时钟可以作为其他时钟的主时钟,也可以作为边界时钟。3.1.32
传输层安全协议transportlayersecurity;TLs一种IP网络安全通信加密协议。3.1.33
透明时钟transparentclock
测量精确时间协议(PTP)事件报文通过该设备的时间,并向接收该PTP事件报文的时钟提供该信息的设备。
传输层transportlayer
OSImodel的第4层,为网络应用提供端到端的通信服务。3.1.35
用户代理
useragent
一种SIP终端设备,例如VoIP电话机。3.1.36
历元epoch
时标的原点。
[GB/T25931—2010,定义3.1.9]3.1.37
快速转发expeditedforwarding
区分服务的其中一种分级,具有低延时,低丢包率和低抖动的特点,适用于语音、视频和其他实时服务。快速转发流量相较于别的流量,通常拥有严格优先级队列。3.1.38
普通时钟ordinaryclock
在一个域中具有单个精确时间协议(PTP)端口,并维护该域中所用时标的时钟。它可作为时问源,即为主时钟;或与另一个时钟同步,即为从时钟。[GB/T25931—2010,定义3.1.23]3.2缩略语
下列缩略语适用于本标准。
ARB任意(Arbitrary)
GY/T304—2016
AVB音视频桥接(AudioVideoBridging)BE尽力转发(BestEffort)
DNS域名服务系统(DomainNameSystem)IEEE电气和电子工程师协会(InstituteofElectricalandElectronicsEngineers)IETF互联网工程任务组(InternetEngineeringTaskForce)IP互联网协议(InternetProtocol)IPv4互联网协议版本4(InternetPralocolversion4)IPv6
互联网协议版本6(InternetProtocolversion6)会话公告协议(SessionAnnounceentPratocol)会话发起协议(SessionInitiationProtocol)用户数据报协议(UserDatagramProtocol)统一资源标识符(UniformResourceIdentifier)URI
4同步
4.1概述
高性能流化音频区别于低性能流化音频(如互联网广播和IP电话)之处是运行前者的设备或应用可共用一套精确的统一时钟。通过时钟的统一,网络中的任何一台接收器都能与其他的接收器同步回放。通过时钟的统一,发送器和接收器之间的延时固定并可测量。统一时钟确保所有流的采样速率和还原速率相同。接收器更易于合成具有相同采样率的音频数据流。这一特性对网络音频设备的高效运行特别关键,如数字调音台。
时钟的同步应通过GB/T25931一2010中规定的精确时间协议(PTP)来实现。GB/T25931一2010定义了各种同步传输应用类别(profile)。这些类别描述了协议的属性、可选项和设备的性能需求。GB/T25931一2010为延时请求-响应机制(GB/T25931一2010附录T中J.3)和点到点延时机制(GB/T259312010中J.4)定义了缺省的类别。除了部分AVB设备(见下段)外,其他设备均应支持GB/T25931一2010缺省的类别。支持缺省类别的设备应使用GB/T25931—2010附录D规定的IPv4封装,唯一的例外是,两种设备不需要实现GB/T25931一2010缺省的类别,一种是4.4中描述的使川AVB同步机制的设备,另种是为完成媒体流传输而连接到AVB网络的设备。4.2IP网络同步
标准IP网络中的设备宜使用附录A中定义的媒体类别,以确保为各种应用提供所需的性能,也可使用缺省类别,但锁定时间会延长、精度会降低。4.3GB/T25931—2010网络同步
在GB/T25931一2010(边界时钟或透明时钟)交换机构建的网络上恰当地使用缺省类别,可满足音频传输所需的性能。
:一些GB/T25931-2010网络设备可能不支持媒类别。注:由于性能的限制,
4.4AVB网络同步
IEEE802.1Q—2011中定义的增强型以太网(即音视频桥接,AVB)按照IEEE802.1AS—2011的规定分发同步信息。1EEE802.1AS一—2011定义了一个GB/T25931一2010的类别。相对于缺省类别或媒体类别,AVB网络可优先使用自有的IEEE802.1AS—2011同步类别。使用GB/T25931—2010和IEEE802.1AS一2011搭建异构同步网络的方法参见附录B。5媒体时钟
GY/T304—2016
发送器使用媒体时钟进行采样,接收器使用媒体时钟播放数字媒体流。媒体时钟与网络时钟存在确定的对应关系。媒体时钟与网络时钟应共用GB/T25931一2010中7.2.2定义的历元,即1970年1月1日00:00:00TAI,通过网络传输的数字音频应根据媒体时钟进行采样,或者根据媒体时钟转换采样频率。
注:由于1972年伊始引入了闫秒,1972年及之后的TAI和UTC时间戳的偏移量变成了整数秒,而1971年及之前该值为非整数秒。这导致出现了另一个可用的历元--1969年12月31日23:59:51.999918UTC,见GB/T25931—2010中7.2.2。这种非整秒的UTC时间偏移量仅在1972年之前的网络时钟时间中存在,与网络时钟相比,媒体时钟拥有更精准的速率,此速率应与音频采样率相同。本标准支持三种采样率:44.1kllz、48kllz和96kllz(见7.2)。在一秒网络时钟中,如果音频流的采样率为48kHz,则媒体时钟前进48000个采样时间。在GB/T25931一2010中7.2.2定义的历元,媒体时钟的值应为0,每一个采样周期过后自动加1。RTP时钟相对媒体时钟有恒定的偏移量,此偏移量应在每个流的会话描述(见8.4)中表示。在网络协议和管理接口中,RTP和媒休时钟通带以32位整数表示。48kl[z流的媒体时钟大约每24.86小时会产生溢出。为了确保与网络时钟司步,以32位整数表示的媒体时钟应准确地处理所有发生在历元与当前时间之间的溢出(反转)。6传输
6.1概述
本章介绍编码和封包的媒体数据如何在网络中传输。基于开放式系统互联模型(OSImode1),本章定义第3层(网络层)和第4层(传输层)上的操作方式。本标准并未规定如何在OSImodel的更低层实现互操作。
本标准是基于理想的TP网络传输技术。注:IP报文在以太网上的传输标准见RFC894。6.2网络层
媒体数据包应使用RFC791中定义的IPv4传输。注1:本标准暂不支持IPv6。
尽管RFC791中要求支持分片数据包重组,但本标准对接收器不作此要求。不支持分片数据包重组的接收器应忽略IP分片数据包。发送器可在传出的媒体数据包的IP包头中设置禁止拆分标记(DF)位。如果网络要对标记为DF的数据包进行分片,此数据包将被丢弃,发送器将收到ICMP“TooBig”消息。发送器在收到此消息后,宜终止传输该流。
组播消息,例如同步消息,应使用RFC1112中描述的IP组播实现。注2:有关1P组播的更多信息见RFC3170所有设备应支持RFC2236中定义的1GMPv2,也可支持RFC3376中定义的1GMPv3。注3:上文提出支持IGMPv2的要求是因为运行于IGMPv2网络中的IGMPv3设备需两分钟启动延时来否找网络中的IGMPv3服务。
注4:RFC2236和RFC3376提出了向下兼容的要求。支持IGMPv2的设各可以在IGMPv1或IGMPv2的网络中正常运行。支持IGMPv3的设备可以在IGMPv1、IGMPv2或IGMPv3的网络中正常运行。设备应使用互联网组管理协议(IGMP)来请求接收所需的组播,包括接收同步信息(见GB/T25931一2010附录1中D.3)、使用组播寻址的媒体流(见7.7)以及设备上可能使用的其他应用协议信息(例如第9章的发现服务)。
注5:在某些路由重新配置的情况下,1GMP注册数据可能会被网络清除,这可能会导致流数据中断。重传1GMH成员报告,是一种有效的快速恢复服务的方法,可通过关闭并立即亘启受影响的组播网络套接字来实现。在发送组播媒体数据包之前,发送器应使用IGMP协议向接收器发送查询并收到确认报文。注6:通过发送1GMP请求,发送器实际上不会接收到它发送的数据包,而是为了阻止不必要的组播媒体数据泛滥。有些IGMP探测的实现可能会造成无注册成员的组播组数据包泛温。7
GY/T304—2016
注7:这种需求通常以发送器接收实时传输控制协议(RTCP)消息的方式实现。在RFC3550中,量然建议但不强求设备发送或接收RTCP数据包。6.3服务质量
若网络中同时存在无管理的非实时流量和时间敏感的媒体流量时,后者通常具备优先处理权,即QoS。为了在网络中有效实施适当的QoS策略,设备应使川RFC2474中所述的区分服务方法。区分服务会根据流量分级,通过IP包头中的DSCP字段来标记数据包,这样网络就能轻易识别需要优先处理的数据包。
所支持的流量等级划分最少应包含表1中所示的三种。设备应使用合适的DSCP值标记输出的流量。对于设备,DSCP字段宜使用表1所示的缺省值,但网络管理员或用户也可以通过管理接口,以其他的DSCP值标记流量。发送器可对多个等级使用同DSCP值,以达到等级合并的效果。本标准不要求设备具有管理接口,设备可仅使用缺省值。当有极低传输延时需求的媒体流与使用较长包时间的媒体流以同QoS等级传输时,前者可能无法在网络中得到低延时的传输保障。为了区别对待有不同需求的媒体流,发送器可配置使用表1规定之外的服务等级。
表1QoS等级与区分服务的对应关系等级名称
尽力转发
流量类型
GB/T25931-2010规定的Anncunce,Sync,Follow_Up,Delay_RegDelay_Resn,Pdelay_Req,Pdelay_Resp和Pdelay_Resn_Follow_Up串
RTP和RTCP媒体流数据
GB/T25931-2010规定的信令与管理消息、发现和连接管理消息缺省区分服务等级
(DSCP十进制值)
EF (46)
AF41(34)
注1:数据包上的DSCP标记并未定义网络设备的任何特定行为,或暗示网络应执行的特定策略。作为一种安全措施,网络基至可忽路传入的DSCP标记,转而通过其他方式(例如:UDP端口号:IP寻址)双流量进行识别和分级。此类网络问题不在本标准范围内,但附录C为网络管理员提供了指导性建议注2:对于本标准范围外的DSCP标记,本标准末做规定。大部分系统将其他应用产生的流量标记为DF(0),这与本标准的要求一致。
对传出的RTCP数据包,发送器宜使用与其对应的RTP流数据包相同的DSCP值进行标记。接收器如果传输类似的流,对于传出的RTCP数据包,宜使用与其对应的RTP数据包相同的DSCP值进行标记。接收器不应根据接收到的数据包的DSCP标记做任何等级关联假设注3:DSCP标记在网络路由过程中可能会被更改。发送器也可能在不通知接收器的情况下更改DSCP标记。6.4传输层
传输层为网络设备之间提供端到端的通信。传输层处理数据包丢失和重新排序问题,以及实现多路复用,使用单个网络连接能为终端站点上的多个应用提供服务。设备应使用RFC3550中定义的实时传输协议。设备应运行与RFC3551中定义的满足最低控制要求的音视频会议一致的RTP类别。设备宜使用为RTP分配的缺省端口:RTP使用5001,RTCP使用5005(见RFC3551第8章)。发送器可使用其他端口。接收器应支持对应的端口。设备应使用RFC768中定义的UDP协议传输RTP数据包,本标准不支持数据包分片,也不要求接收器重组(见6.2),同时假设以太网采用1500字节的最大传输单元(MTL),为防止数据包在标准的IPv1以太网中传输时出现分片,以及确保日后与IPv6兼容,最大的RTP有效载荷应为1440字节。注:在MIU比以太网的150U字节更小的网络连接中,发送器可能希望使用更小的最大有效载8
小提示:此标准内容仅展示完整标准里的部分截取内容,若需要完整标准请到上方自行免费下载完整标准文档。