CN101197642A - 一种网络电视直播丢包的解决方法 - Google Patents
一种网络电视直播丢包的解决方法 Download PDFInfo
- Publication number
- CN101197642A CN101197642A CNA2006101606777A CN200610160677A CN101197642A CN 101197642 A CN101197642 A CN 101197642A CN A2006101606777 A CNA2006101606777 A CN A2006101606777A CN 200610160677 A CN200610160677 A CN 200610160677A CN 101197642 A CN101197642 A CN 101197642A
- Authority
- CN
- China
- Prior art keywords
- multicast
- packet loss
- live broadcast
- transmission control
- control protocol
- 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
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供了一种网络电视直播丢包的解决方法,首先直播服务器在进行组播时以包的形式缓存一段最近播出的流媒体数据,当客户端接入某个直播频道时,加入组播组并建立可靠的传输控制协议链接,如果客户端检测到组播丢包,便通过传输控制协议链接请求直播服务器重传丢失的包,恢复丢包数据。采用本发明的方法可以用很小的开销解决宽带接入网络的直播丢包问题,提高用户体验质量,同时可以降低直播业务对宽带接入网的接入带宽要求,降低了建网成本。
Description
技术领域
本发明属于网络电视(Internet Protocol Television,以下简称IPTV)技术领域,特别涉及一种IPTV直播丢包的解决方法。
背景技术
随着宽带接入技术、数据通信技术和多媒体技术的发展,作为宽带增值业务的IPTV业务得到了蓬勃的发展。在IPTV业务中,直播业务占据非常重要的地位,是基础业务之一。在IP网络中开展直播业务一般采用IP组播方式来进行视频流的复制和传输,其传输层协议为用户数据报文协议(user datagram protocol,以下简称UDP)。UDP协议不保证通信的可靠性,即使传输过程中产生丢包,也不能恢复。这样如果没有一定的恢复机制,在用户端必然造成解码失败,在屏幕上表现就是出现马赛克、停顿等异常现象,严重影响观看效果。同时,IPTV业务和原有的互联网业务是由同一宽带接入网络承载,其突发冲突引起的瞬间丢包不可避免。另外,典型运动图像专家组(Motion Picture Experts Group,以下简称MPEG)码流是变速率的,其中关键帧的信息量最大,也即关键帧信息最容易引起丢包,而根据MPEG编解码规则,关键帧丢失不仅影响本身解码失败,而且会引起关联的其它帧的解码失败,这样就会引起更加严重的视频异常。在实际的工程应用中,也确实出现上述现象,其解决办法一般是加大线路带宽,这无疑增加了网络建设成本。
发明内容
本发明的目的是提供一种组播和单播重传相结合的方法来解决基于组播的IPTV直播业务丢包问题,提高用户体验质量。
本发明提供一种IPTV直播丢包的解决方法,首先直播服务器在进行组播时以包的形式缓存一段最近播出的流媒体数据,当客户端接入某个直播频道时,加入组播组接收组播流,并与直播服务器建立可靠的传输控制协议(Transmission Control Protocol,以下简称TCP)链接,如果客户端检测到组播丢包,便通过TCP链接请求直播服务器重传丢失的包,恢复丢包数据。
其中,上述TCP链接为TCP重传通道,其也可以是任何合适形式的TCP链接。直播服务器可以是流媒体服务器或其他合适的服务器,其缓存的包可以为实时传输协议包(Real Time Transport Protocol,以下简称RTP)包。客户端可以包括机顶盒,也可以包括其他合适的设备以及设备的组合,其通过互联网组管理协议(Internet Group Management Protocol,以下简称IGMP)加入组播组。组播为UDP组播。流媒体数据可以为视频信号数据或其他任何合适的数据。
由于直播服务器仅仅重传少量的丢包数据,不会对其性能造成大的影响。另外,客户端一般都具有一定大小的缓冲区,因此,快速重传丢包数据不会造成视频播放的停顿。所以,采用本发明的方法可以用很小的开销解决宽带接入网络的直播丢包问题,提高用户体验质量,同时可以降低直播业务对宽带接入网的接入带宽要求,降低了建网成本。
下面结合附图,对本发明的具体实施方式作进一步的详细说明。对于所属技术领域的技术人员而言,从对本发明的详细说明中,本发明的上述和其他目的、特征和优点将显而易见。
附图说明
图1是表示本发明一较佳实施例的IPTV直播***框图。
具体实施方式
下面结合附图和具体实施例对本发明所述的IPTV直播丢包的解决办法作进一步的详细说明。
如图1所示,视频信号首先输入编码器101进行编码,然后将已流化的IP码流传输到流媒体服务器102,再经流媒体服务器102转换成组播流向机顶盒103播出。编码器101和流媒体服务器102都是挂接在城域网中,由于目前城域网的负荷一般较轻,网络线路质量也较好,通常不会产生丢包,故两者之间一般采用UDP传输即可。不过,如网络情况不太好,则须采用TCP传输。流媒体服务器102与机顶盒103之间一般可以采用单向的UDP组播。对机顶盒103而言,为了适应IP网络的时延抖动,一般必须配置缓存。视频信号从编码器101输入到机顶盒103解码输出视频信号之间的延时一般要求在5s以内。
本发明一较佳实施例的IPTV直播丢包的解决方法包括以下步骤:
第一步,流媒体服务器102对每个频道的码流进行缓存,缓存时间为任意,建议为8s,而一个2M码流的频道一般需要2MB的内存缓存;
第二步,流媒体服务器102延时1s播出组播流;
第三步,在机顶盒103和流媒体服务器102之间建立并保持一条常设的TCP重传通道;
第四步,机顶盒103接收组播流,并自动检测组播丢包;
第五步,如果检测出丢包,则通过TCP重传通道要求流媒体服务器102重传丢失的数据包;
第六步,把重传的数据包组帧送解码器进行解码播放输出。
以上所述仅为本发明的较佳实施例,并非用来限定本发明的实施范围;如果不脱离本发明的精神和范围,对本发明进行修改或者等同替换的,均应涵盖在本发明的权利要求的保护范围当中。
Claims (6)
1.一种网络电视直播丢包的解决方法,其特征在于,直播服务器在进行组播时以包的形式缓存一段最近播出的流媒体数据,当客户端接入某个直播频道时,加入组播组接收组播流,并与直播服务器建立可靠的传输控制协议链接,如果客户端检测到组播丢包,便通过传输控制协议链接请求直播服务器重传丢失的包,恢复丢包数据。
2.根据权利要求1所述的方法,其特征在于,上述传输控制协议链接为传输控制协议重传通道。
3.根据权利要求2所述的方法,其特征在于,上述直播服务器包括流媒体服务器,其缓存的包为实时传输协议包。
4.根据权利要求2所述的方法,其特征在于,上述客户端包括机顶盒,通过互联网组管理协议加入组播组。
5.根据权利要求1或4所述的方法,其特征在于,上述组播为单项用户数据报文协议组播。
6.根据权利要求5所述的方法,其特征在于,上述流媒体数据为视频信号数据。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2006101606777A CN101197642A (zh) | 2006-12-04 | 2006-12-04 | 一种网络电视直播丢包的解决方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNA2006101606777A CN101197642A (zh) | 2006-12-04 | 2006-12-04 | 一种网络电视直播丢包的解决方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101197642A true CN101197642A (zh) | 2008-06-11 |
Family
ID=39547814
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2006101606777A Pending CN101197642A (zh) | 2006-12-04 | 2006-12-04 | 一种网络电视直播丢包的解决方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101197642A (zh) |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102098587A (zh) * | 2011-01-18 | 2011-06-15 | 中国联合网络通信集团有限公司 | Iptv服务质量保障方法及媒体服务器 |
CN103533387A (zh) * | 2013-10-21 | 2014-01-22 | 腾讯科技(深圳)有限公司 | 一种视频直播控制方法、设备及*** |
CN103686446A (zh) * | 2013-12-06 | 2014-03-26 | 广州华多网络科技有限公司 | 视频数据传输的丢包重传方法和*** |
CN104378677A (zh) * | 2014-11-19 | 2015-02-25 | 青岛海信网络科技股份有限公司 | 一种车载终端视频切换控制方法 |
CN105357577A (zh) * | 2014-08-22 | 2016-02-24 | 中兴通讯股份有限公司 | 一种丢包重传方法及装置 |
CN105933319A (zh) * | 2016-05-30 | 2016-09-07 | 贵阳朗玛信息技术股份有限公司 | 视频数据包的发送、接收方法及装置 |
CN106209915A (zh) * | 2016-08-31 | 2016-12-07 | 深圳聚点互动科技有限公司 | 一种实时流媒体无线传输方法及其*** |
CN107547921A (zh) * | 2016-06-29 | 2018-01-05 | 中兴通讯股份有限公司 | 视频播放方法、装置及*** |
CN108234420A (zh) * | 2016-12-21 | 2018-06-29 | 北京酷我科技有限公司 | 一种解决流媒体丢失视频头的***及方法 |
CN108282277A (zh) * | 2018-01-22 | 2018-07-13 | 西安万像电子科技有限公司 | 一种丢包重传方法、装置及*** |
CN109155862A (zh) * | 2016-08-19 | 2019-01-04 | 惠州Tcl移动通信有限公司 | 一种视频流数据传输方法、基站及用户设备 |
CN110545486A (zh) * | 2019-08-05 | 2019-12-06 | 广州珠江数码集团股份有限公司 | 一种视频信号传输方法、装置、介质及终端设备 |
CN111953653A (zh) * | 2020-07-07 | 2020-11-17 | 上海金仕达软件科技有限公司 | 数据传输方法、***及装置 |
CN112040266A (zh) * | 2020-09-10 | 2020-12-04 | 紫光云(南京)数字技术有限公司 | 基于内核转发的udp直播业务优化方法 |
CN114125508A (zh) * | 2021-10-22 | 2022-03-01 | 北京邮电大学 | 无线域内视频组播的可靠性保障方法 |
-
2006
- 2006-12-04 CN CNA2006101606777A patent/CN101197642A/zh active Pending
Cited By (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102098587B (zh) * | 2011-01-18 | 2012-12-12 | 中国联合网络通信集团有限公司 | Iptv服务质量保障方法及媒体服务器 |
CN102098587A (zh) * | 2011-01-18 | 2011-06-15 | 中国联合网络通信集团有限公司 | Iptv服务质量保障方法及媒体服务器 |
CN103533387B (zh) * | 2013-10-21 | 2016-08-17 | 腾讯科技(深圳)有限公司 | 一种视频直播控制方法、设备及*** |
CN103533387A (zh) * | 2013-10-21 | 2014-01-22 | 腾讯科技(深圳)有限公司 | 一种视频直播控制方法、设备及*** |
CN103686446A (zh) * | 2013-12-06 | 2014-03-26 | 广州华多网络科技有限公司 | 视频数据传输的丢包重传方法和*** |
CN105357577A (zh) * | 2014-08-22 | 2016-02-24 | 中兴通讯股份有限公司 | 一种丢包重传方法及装置 |
WO2016026299A1 (zh) * | 2014-08-22 | 2016-02-25 | 中兴通讯股份有限公司 | 一种丢包重传方法及装置 |
CN104378677B (zh) * | 2014-11-19 | 2017-06-20 | 青岛海信网络科技股份有限公司 | 一种车载终端视频切换控制方法 |
CN104378677A (zh) * | 2014-11-19 | 2015-02-25 | 青岛海信网络科技股份有限公司 | 一种车载终端视频切换控制方法 |
CN105933319A (zh) * | 2016-05-30 | 2016-09-07 | 贵阳朗玛信息技术股份有限公司 | 视频数据包的发送、接收方法及装置 |
CN107547921A (zh) * | 2016-06-29 | 2018-01-05 | 中兴通讯股份有限公司 | 视频播放方法、装置及*** |
CN109155862A (zh) * | 2016-08-19 | 2019-01-04 | 惠州Tcl移动通信有限公司 | 一种视频流数据传输方法、基站及用户设备 |
CN106209915A (zh) * | 2016-08-31 | 2016-12-07 | 深圳聚点互动科技有限公司 | 一种实时流媒体无线传输方法及其*** |
CN108234420A (zh) * | 2016-12-21 | 2018-06-29 | 北京酷我科技有限公司 | 一种解决流媒体丢失视频头的***及方法 |
CN108282277A (zh) * | 2018-01-22 | 2018-07-13 | 西安万像电子科技有限公司 | 一种丢包重传方法、装置及*** |
CN110545486A (zh) * | 2019-08-05 | 2019-12-06 | 广州珠江数码集团股份有限公司 | 一种视频信号传输方法、装置、介质及终端设备 |
CN110545486B (zh) * | 2019-08-05 | 2022-04-05 | 广州珠江数码集团股份有限公司 | 一种视频信号传输方法、装置、介质及终端设备 |
CN111953653A (zh) * | 2020-07-07 | 2020-11-17 | 上海金仕达软件科技有限公司 | 数据传输方法、***及装置 |
CN112040266A (zh) * | 2020-09-10 | 2020-12-04 | 紫光云(南京)数字技术有限公司 | 基于内核转发的udp直播业务优化方法 |
CN114125508A (zh) * | 2021-10-22 | 2022-03-01 | 北京邮电大学 | 无线域内视频组播的可靠性保障方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101197642A (zh) | 一种网络电视直播丢包的解决方法 | |
CN101316357B (zh) | 一种频道切换的方法和终端 | |
US7984179B1 (en) | Adaptive media transport management for continuous media stream over LAN/WAN environment | |
US7653055B2 (en) | Method and apparatus for improved multicast streaming in wireless networks | |
JP4943513B2 (ja) | Iptvの低ビットレートのストリームを使用したビデオデータ損失回復システム | |
US8776161B2 (en) | Systems and methods for video processing in network edge devices | |
CN1787639B (zh) | 通过代码转换器传送视频数据的方法和接收视频数据的方法 | |
US7881335B2 (en) | Client-side bandwidth allocation for continuous and discrete media | |
US20080192646A1 (en) | Method for Monitoring Quality of Service in Multimedia Communications | |
CN106911699B (zh) | 一种基于rtp协议实现i帧重传的方法 | |
Greengrass et al. | Not all packets are equal, part i: Streaming video coding and sla requirements | |
US20080263616A1 (en) | Method and Device for Transferring Predictive and Non-Predictive Data Frames | |
CN101742271A (zh) | 流媒体数据的传输方法、***和装置 | |
US7852853B1 (en) | System and method for transmitting video information | |
Jennehag et al. | Increasing bandwidth utilization in next generation IPTV networks | |
KR100780396B1 (ko) | Iptv 방송 서비스의 트래픽 제어 방법 | |
Zare et al. | An FEC scheme combined with weighted scheduling to reduce multicast packet loss in IPTV over PON | |
US8645801B2 (en) | Delivery method for internet protocol television (IPTV) | |
KR100792025B1 (ko) | Iptv 시스템에서 채널 변경시 비디오 데이터 전송 방법 | |
CN101090369B (zh) | 一种在流媒体***中控制数据包发送速率的方法 | |
US20100299448A1 (en) | Device for the streaming reception of audio and/or video data packets | |
JP2005033556A (ja) | データ送信装置、データ送信方法、データ受信装置、データ受信方法 | |
KR101625663B1 (ko) | 콘텐트를 수신하기 위한 방법 및 장치 | |
Zare et al. | Congestion control in IPTV over PON using Digital Fountain forward error correction | |
Uzunalioglu | Channel change delay in IPTV systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |
Open date: 20080611 |