CN108600861A - 基于城市轨道乘客信息系统的音视频数据包包长调整方法 - Google Patents
基于城市轨道乘客信息系统的音视频数据包包长调整方法 Download PDFInfo
- Publication number
- CN108600861A CN108600861A CN201810252315.3A CN201810252315A CN108600861A CN 108600861 A CN108600861 A CN 108600861A CN 201810252315 A CN201810252315 A CN 201810252315A CN 108600861 A CN108600861 A CN 108600861A
- Authority
- CN
- China
- Prior art keywords
- data packet
- audio
- sent
- transmission unit
- packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
- H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了基于城市轨道乘客信息系统的音视频数据包包长调整方法,包括以下步骤:在操作系统中设定不拆分定位标记位;将一个指定大小的数据包不经过拆分发往目的端,判断是否能够送达:若未能送达则获得最大传输单元大小;若能够送达则发送的数据包加一个字节,重复该步骤直至数据包不能送达至目的端,获得最大传输单元大小;计算最大传输单元能够容纳TS包个数;用TS流的数据包包长乘以最大传输单元能够容纳的TS包个数即得到音视频编码UDP数据包大小。本发明调整音视频编码的UDP包长,使得数据包在网络层传输时不需要拆分,对于提高整个LTE网络利用效率是非常重要的,避免重新传输丢失的数据包,可以确保音视频解码的流畅性。
Description
技术领域
本发明涉及通信技术领域,尤其涉及基于城市轨道乘客信息系统的音视频数据包包长调整方法。
背景技术
在城市轨道交通系统工程中,乘客信息系统(Passenger Information System,以下简称PIS)的一个重要功能是地铁列车上的音视频直播。要实现该功能,首先需要在PIS控制中心的编码器将直播信号进行音视频编码。
编码器在对直播信号编码后,按照DVB标准将直播数据打包成UDP包,并以组播的方式输入到PIS网络。音视频直播数据包通过LTE车地无线网络传输到列车,并由车载播放控制器解码播放。
该线路建设的1.8GHz频段LTE车地无线网络能够提供的总数据带宽大约为8Mbps,包括上下行,但是需要同时承载信号系统、视频监控系统、PIS三个业务。
音视频编码数据的特点是数据量很大,按照PIS的功能要求,列车音视频直播的编码码率一般要求达到2~6Mbps,而LTE车地无线网络承载的三个业务中,除了信号系统的数据码率较低外(Kbps量级),其他两个业务都是音视频业务,都要求较高的带宽来传输。信号系统是列车行进控制的安全保障系统,在三个业务中优先级是最高的,视频监控系统则是安防反恐的重要辅助手段,优先级次之,PIS业务是三个业务中优先级最低的。
由于无线网络无法做到有线网络那么稳定可靠,在传输数据的过程中会由于信号干扰导致数据丢失,因此为了能够有效的在LTE车地无线网络上传输UDP形式的直播音视频数据包,应该避免一个音视频编码UDP数据包被网络拆分成两个包传输,否则一旦其中的一个拆分包丢失,就会导致整个音视频编码UDP数据包丢失。
车载上进行音视频解码播放时,如果发生数据包丢失的情况,会导致卡顿和马赛克现象,影响到乘客的观感体验,数据丢的越多,卡顿和马赛克现象就越严重。因此在遇到数据包丢失时,需要将丢失的数据包补充回来。如果补充的数据包也被拆分传输的话,势必会占用更多的带宽。
发明内容
本发明旨在解决在LTE车地无线网络上传输UDP形式的直播音视频数据包时受到信号干扰出现音视频编码UDP数据包被网络拆分成两个包传输而导致数据丢失的问题。
为了实现上述目标,本发明采用以下的技术方案:本发明提供了基于城市轨道乘客信息系统的音视频数据包包长调整方法,其特征在于包括以下步骤:
(1)在操作系统中设定不拆分定位标记位;
(2)将一个指定大小的数据包不经过拆分发往目的端,判断是否能够送达:
若未能送达则获得最大传输单元大小;
若能够送达则发送的数据包加一个字节,重复该步骤直至数据包不能送达至目的端,获得最大传输单元大小;
(3)计算最大传输单元能够容纳TS包个数;
(4)用TS流的数据包包长乘以最大传输单元能够容纳的TS包个数即得到音视频编码UDP数据包大小。
本发明所达到的有益效果:本发明基于城市轨道乘客信息系统的音视频数据包包长调整方法,使得数据包在网络层传输时不需要拆分,对于提高整个LTE网络利用效率是非常重要的,避免重新传输丢失的数据包,可以确保音视频解码的流畅性。
附图说明
图1是本发明方法的流程图;
图2是UDP/IP包结构示意图;
图3是UDP包结构示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚,下面对本发明作进一步描述。应当理解,以下实施例仅用于更加清楚地说明本发明的技术方案,而不能以此来限制本发明的保护范围。
UDP是User Datagram Protocol的简称,中文名是用户数据报协议,是OSI(OpenSystem Interconnection,开放式系统互联)参考模型中一种无连接的传输层协议,提供面向事务的简单不可靠信息传送服务,IETF RFC 768是UDP的正式规范。UDP在IP报文的协议号是17。
UDP协议与TCP协议一样用于处理数据包,但是不一样的是,UDP是一种无连接的协议。UDP协议直接位于IP(网际协议)协议的顶层。根据OSI(开放系统互连)参考模型,UDP和TCP都属于传输层协议。UDP协议的主要作用是将网络数据流量压缩成数据包的形式。一个典型的数据包就是一个二进制数据的传输单位。每一个数据包的前8个字节用来包含报头信息,剩余字节则用来包含具体的传输数据。
UDP报文没有可靠性保证、顺序保证和流量控制字段等,可靠性较差。但是正因为UDP协议的控制选项较少,在数据传输过程中延迟小、数据传输效率高,适合于传输音视频数据。UDP包在IP包中的位置图2所示。
UDP报头由4个域组成,其中每个域各占用2个字节,具体如图3所示。
端口号分为源端口号和目的端口号,用于描述发送端和接收端应用的数据通道。UDP长度是指包括报头和数据部分在内的总字节数。由于包头长度是固定的,所以该域主要被用来计算数据部分的长度。从理论上说,UDP长度域占用16比特位,因此包含报头在内的数据报的最大长度为2^16=65535字节。
图1是本发明方法的流程图;在图1中示出了本发明方法的流程:具体包括:
(1)在操作系统中设定不拆分定位标记位;
MTU(Maximum Transmission Unit,最大传输单元)是指一种通信协议的某一层上面所能通过的最大数据包大小,对于TCP/IP来说,就是TCP包和UDP包的最大大小(以字节为单位),虽然上面提到UDP包的最大长度为65535字节,但那是面向应用层,对于网络层,如果一个数据包超过了MTU,虽然该数据包也能继续传输,但是会被网络层驱动拆分成一个个不超过MTU的数据包再传输,然后在接收端在重新组合成完成的数据包。在传输的过程中,即使仅仅一个拆分的小包丢失,也会导致整个数据包被丢弃。
因此,在PIS中实现车载音视频直播时,打包形成的UDP包不应该超过MTU大小,以提高传输的效率。
进一步地,在windows和linux两大主流操作系统中,socket是网络数据通信的具体实现,通过设定DF标记位(don't fragment flag,意思是不拆分)可以将一个指定大小的数据包不经过拆分发往目的端,如果该数据包能够送达,说明网络MTU比该数据包大小大,可以再尝试发送更大的数据包。
Windows系统:
int val=1;
setsockopt(sd,IPPROTO_IP,IP_DONTFRAG,&val,sizeof(val));
linux系统:
int val=IP_PMTUDISC_DO;
setsockopt(sd,IPPROTO_IP,IP_MTU_DISCOVER,&val,sizeof(val));
(2)将一个指定大小的数据包不经过拆分发往目的端,判断是否能够送达:
若未能送达则获得最大传输单元大小;
若能够送达则发送的数据包加一个字节,重复该步骤直至数据包不能送达至目的端,获得最大传输单元大小;
(3)计算最大传输单元能够容纳TS包个数;
为了进一步说明计算最大传输单元能够容纳TS包个数;以下为本发明的一个实施例。
编码器通过上述方法探测到MTU大小后,首先需要计算出留给负载的数据长度,算法如下:
length=MTU–IP包长–UDP包长,
其中IP包长为20字节,UDP包长为8字节。
对于普通以太网来说,MTU一般为1500字节,那么留给负载的数据长度为:
length=1500–20–8=1472,
按照DVB标准,TS流由一个个数据包构成,TS包包长有188、204个字节,一般188包长的应用较多。因此,一个MTU包能够容纳的TS包个数如下:
需要说明的是这里length/TS包长采用向下取整。
在普通以太网中,计算如下:
(4)用TS流的数据包包长乘以最大传输单元能够容纳的TS包个数即得到音视频编码UDP数据包大小。
因此,普通以太网中,实际的音视频编码UDP数据包大小为:
size=7*188=1316
本发明方法在南京宁高线的LTE车地无线网络在实际实现时,经探测,其MTU为1500。为了比较音视频编码的UDP数据包在拆分和不拆分情况下的数据传输效率,专门对编码器的输出设置了两种UDP包长,并测试两种情况下的数据传输情况,结果表1。
表1
序号 | 包长 | 拆分 | 传输量 | 总数据包数 | 丢失包数 | 丢失比率 |
1 | 1316 | 否 | 100MB | 79679 | 75 | 0.094% |
2 | 1504 | 是 | 100MB | 69719 | 111 | 0.16% |
不管传输任何数据,在LTE网络中,对于1316包长,总数据包个数为79679,由于不需要拆分,对于LTE网络来说,数据包个数也是79679;然而对于1504包长来,总数据包个数为69719,虽然少了,但是对于LTE网络来说,由于需要拆分,实际的数据包个数变成了69719*2=139438。拆分的数据包,一旦其中一个丢失,整个数据包就会丢弃,因此在LTE网络层丢包率基本一致的情况下,1504包长的数据丢失率更高是正常的。
本发明调整音视频数据包包长,使得数据包在网络层传输时不需要拆分,对于提高整个LTE网络利用效率是非常重要的,避免重新传输丢失的数据包,可以确保音视频解码的流畅性。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明技术原理的前提下,还可以做出若干改进和变形,这些改进和变形也应视为本发明的保护范围。
Claims (6)
1.基于城市轨道乘客信息系统的音视频数据包包长调整方法,其特征在于包括以下步骤:
(1)在操作系统中设定不拆分定位标记位;
(2)将一个指定大小的数据包不经过拆分发往目的端,判断是否能够送达:
若未能送达则获得最大传输单元大小;
若能够送达则发送的数据包加一个字节,重复该步骤直至数据包不能送达至目的端,获得最大传输单元大小;
(3)计算最大传输单元能够容纳TS包个数;
(4)用TS流的数据包包长乘以最大传输单元能够容纳的TS包个数即得到音视频编码UDP数据包大小。
2.根据权利要求1所述的基于城市轨道乘客信息系统的音视频数据包包长调整方法,其特征在于,步骤(1)中所述操作系统包括Windows系统和linux系统。
3.根据权利要求2所述的基于城市轨道乘客信息系统的音视频数据包包长调整方法,其特征在于,在操作系统中设置不拆分定位标记时通过socket具体实现。
4.根据权利要求1所述的基于城市轨道乘客信息系统的音视频数据包包长调整方法,其特征在于,所述最大传输单元包括20字节的IP包长和8字节的UDP包长。
5.根据权利要求1所述的基于城市轨道乘客信息系统的音视频数据包包长调整方法,其特征在于,计算最大传输单元能够容纳TS包个数通过以下方法:
其中number是最大传输单元能够容纳TS包个数,length是步骤2中获得的最大传输单元减去20字节的IP包长再减去8字节后的UDP包长后的长度,TS包长取188字节。
6.根据权利要求5所述的基于城市轨道乘客信息系统的音视频数据包包长调整方法,其特征在于,计算最大传输单元能够容纳TS包个数时采用向下取整的计算方式。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810252315.3A CN108600861A (zh) | 2018-03-26 | 2018-03-26 | 基于城市轨道乘客信息系统的音视频数据包包长调整方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810252315.3A CN108600861A (zh) | 2018-03-26 | 2018-03-26 | 基于城市轨道乘客信息系统的音视频数据包包长调整方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN108600861A true CN108600861A (zh) | 2018-09-28 |
Family
ID=63623582
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810252315.3A Pending CN108600861A (zh) | 2018-03-26 | 2018-03-26 | 基于城市轨道乘客信息系统的音视频数据包包长调整方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108600861A (zh) |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1669320A (zh) * | 2002-07-16 | 2005-09-14 | 松下电器产业株式会社 | 内容接收器和内容发送器 |
CN1716943A (zh) * | 2004-06-28 | 2006-01-04 | 杭州华为三康技术有限公司 | 获取隧道网关环境中路径最大传输长度的方法及系统 |
CN101459809A (zh) * | 2008-11-26 | 2009-06-17 | 天柏宽带网络科技(北京)有限公司 | 一种数字电视节目播放的方法和系统 |
CN103313045A (zh) * | 2013-05-31 | 2013-09-18 | 哈尔滨工业大学 | 宽带多媒体集群系统调度台h.264视频分包方法 |
CN107277648A (zh) * | 2017-02-28 | 2017-10-20 | 大连理工大学 | 一种地铁列车lcd屏的视频传输方法 |
CN107342946A (zh) * | 2017-05-12 | 2017-11-10 | 广东网金控股股份有限公司 | 一种基于自协商的通信方法及终端 |
-
2018
- 2018-03-26 CN CN201810252315.3A patent/CN108600861A/zh active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1669320A (zh) * | 2002-07-16 | 2005-09-14 | 松下电器产业株式会社 | 内容接收器和内容发送器 |
CN1716943A (zh) * | 2004-06-28 | 2006-01-04 | 杭州华为三康技术有限公司 | 获取隧道网关环境中路径最大传输长度的方法及系统 |
CN101459809A (zh) * | 2008-11-26 | 2009-06-17 | 天柏宽带网络科技(北京)有限公司 | 一种数字电视节目播放的方法和系统 |
CN103313045A (zh) * | 2013-05-31 | 2013-09-18 | 哈尔滨工业大学 | 宽带多媒体集群系统调度台h.264视频分包方法 |
CN107277648A (zh) * | 2017-02-28 | 2017-10-20 | 大连理工大学 | 一种地铁列车lcd屏的视频传输方法 |
CN107342946A (zh) * | 2017-05-12 | 2017-11-10 | 广东网金控股股份有限公司 | 一种基于自协商的通信方法及终端 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2157749B1 (en) | system and method for achieving accelerated throughput | |
US8948206B2 (en) | Inclusion of quality of service indication in header compression channel | |
Degermark et al. | IP header compression | |
US7286536B2 (en) | Method and system for early header compression | |
US8879491B2 (en) | Wireless terminal for transmitting packets of different types | |
US7649913B2 (en) | Method and system for mitigating traffic congestions in a communication network | |
JP2013526098A (ja) | スループットの高速化を達成するためのシステム及び方法 | |
WO2016034029A1 (zh) | 业务流量的处理方法和装置 | |
US11165893B2 (en) | Techniques for packet data conversion | |
CN106603192A (zh) | 一种基于媒体内容的自适应fec机制 | |
WO2000072532A9 (en) | System and method for network packet reduction | |
US20070230435A1 (en) | Packet relaying apparatus | |
WO2008079200A1 (en) | Header supression in a wireless communication network | |
EP2647169B1 (en) | Method and apparatus for performing actions on packets at intermediate nodes in a connection between a communication device and a destination device in a target network | |
CN110012314B (zh) | 一种基于dtmb的ip传输方法及系统 | |
Degermark et al. | RFC2507: IP header compression | |
Wang et al. | A multiplex-multicast scheme that improves system capacity of voice-over-IP on wireless LAN by 100% | |
US20040034826A1 (en) | Transport protocol checksum recalculation | |
CN108600861A (zh) | 基于城市轨道乘客信息系统的音视频数据包包长调整方法 | |
GB2456913A (en) | TETRA Mobile Communications Systems | |
ES2335571T3 (es) | Procedimiento para la transmision de paquetes de datos. | |
KR101568881B1 (ko) | 헤더 압축 효율 향상 방법 및 그를 위한 패킷 송신 장치 | |
Icart et al. | Optimizations for efficient and transparent use of IP applications over HF links | |
KR20080019143A (ko) | 통신 시스템에서 rohc 피드백 메시지 전송을 위한 방법및 장치 | |
Kidston | IP header compression and packet aggregation in mobile tactical networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20180928 |
|
RJ01 | Rejection of invention patent application after publication |