CN102130821A - 一种iptv***中丢包处理的方法、服务器及*** - Google Patents

Abstract

本发明公开了一种IPTV***中丢包处理方法，包括：解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，确认待发送媒体数据中数据包的重要等级；获取客户端根据接收媒体数据返回的结果信息，该结果信息至少包括客户端接收媒体数据的数据丢失信息；根据数据丢失信息确定当前传输网络的拥塞等级；根据当前传输网络的拥塞等级和数据包的重要等级，结合预先制定的丢包策略进行丢包处理。本发明还公开了一种流媒体服务器和IPTV***中丢包处理***。通过判断网络拥塞等级，结合预先制定的丢包策略，有选择性地、主动丢弃数据包。避免了媒体数据中的关键数据包被随机丢弃，从而导致的无法解码，严重影响信宿端的解码质量问题。

Description

一种IPTV***中丢包处理的方法、服务器及***

技术领域

本发明涉及通信领域，尤其涉及一种在IPTV***中丢包处理的方法、服务器及***。

背景技术

随着流媒体业务发展迅速，流媒体业务的内容和形式丰富多样，越来越多的用户通过机顶盒或移动手机享受各种各样的音视频业务。流媒体业务由于自身的技术特点，业务的广泛应用受到视频编码效率以及网络传输质量的影响。

视频编码技术可以实现视频数据的大量压缩，是流媒体业务广泛开展前提。随着视频编码技术的进步，视频数据编码效率大幅提高，特别是H.264编码算法的推广，推动了流媒体业务的发展。但是，由于受网络带宽的限制，流媒体业务经常出现各种各样影响业务质量(Quality of Service，Qos)的问题。其中，由于网络拥塞导致数据包丢失的问题对用户的体验影响最为严重，经过编码处理后的任何数据丢失，都将影响用户终端的解码播放的图像。

针对网络拥塞导致数据丢失进而影响用户的体验，现有技术一般采用如下方案：

1、超时重传(Automatic Repeat Request，ARQ)技术信宿终端在一定时间内没有收到某个数据报文，信宿端会向信源端发送超时重传的请求，然后信源根据报文的需要进行数据报文的重传。通过数据报的重传，减少传输数据包丢失，提升信宿端解码的质量。但是当网络严重拥塞，丢包(数据包丢失)率超过一定比例时，过度的超时重传不仅会进一步增加网络的拥塞程度，还会导致传输码率的突发，产生更严重的丢包，严重影响一段时间内的网络传输质量。

2、传输控制协议(Transmission Control Protocol，TCP)承载技术信源和信宿之间采用TCP传输方式，信源端发包线程负责读取流媒体数据，并按照固定的速率调用网络层的接口，向网络缓存区写入数据，然后并由网络层独立处理数据的网络发送过程。而网络层根据TCP的流量控制和拥塞控制机制，和信宿端协商数据的发送方式和速率，保证数据完整可靠地被信宿接收。通过TCP传输机制，可以确保信源和信宿之间传输链路上没有数据报文的丢失，但是由于信源服务器的应用层没有实时监控网络层的状况，很可能发生网络层缓存区的写入速率大于读出速率的情况，最终导致发送缓存区溢出，数据报文丢失

采用ARQ技术或者TCP技术，在网络拥塞的情况下，由于数据包都是被随机丢弃的，当丢失的正好是关键数据时将导致其整个一个序列所有帧的图像都无法解码，最终严重影响信宿端解码的质量。导致终端播放的文件出现严重失真、延时，甚至无法播放等问题，用户体验较差。

发明内容

有鉴于此，为了避免在网络拥塞的情况下，由于IPTV***媒体数据中的关键、核心数据包被被动、随机丢弃，从而导致的无法解码，最终严重影响信宿端的解码质量的问题。本发明实施例提供了一种IPTV***中丢包处理方法和服务器。

本发明实施例提供了一种IPTV***中丢包处理方法，包括：

解析待发送媒体数据的网络提取层(Network Abstraction Layer，NAL)头和分片Slice头数据，确认所述待发送媒体数据中数据包的重要等级；

获取客户端根据接收媒体数据返回的结果信息，所述结果信息至少包括所述客户端接收所述媒体数据的数据丢失信息；

根据所述数据丢失信息确定当前传输网络的拥塞等级；

根据所述当前传输网络的拥塞等级和所述数据包的重要等级，结合预先制定的丢包策略进行丢包处理。

另外，本发明实施例还提供了一种流媒体服务器，包括：

分析模块，用于解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，确认所述待发送媒体数据中数据包的重要等级；

获取模块，用于获取客户端根据接收媒体数据返回的结果信息，所述结果信息至少包括所述客户端接收所述媒体数据的数据丢失信息；

确定模块，用于根据所述获取模块获取的所述数据丢失信息确定当前传输网络的拥塞等级；

处理模块，用于根据所述确定模块确定的所述当前传输网络的拥塞等级和所述分析模块确定的所述数据包的重要等级，结合预先制定的丢包策略进行丢包处理。

同时，本发明实施例还提供了一种IPTV***丢包处理***，包括：

客户端，用于接收流媒体服务器发送的媒体数据，并根据接收的所述媒体数据向所述流媒体服务器发送结果信息；

所述流媒体服务器，用于解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，确认所述待发送媒体数据中数据包的重要等级，获取所述客户端返回的结果信息，所述结果信息至少包括所述客户端接收所述媒体数据的数据丢失信息，根据所述数据丢失信息确定当前传输网络的拥塞等级，根据所述当前传输网络的拥塞等级和所述数据包的重要等级，结合预先制定的丢包策略进行丢包处理。

本发明实施例在IPTV***中媒体数据的传输过程中，通过通过解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，确认所述待发送媒体数据中数据包的重要等级和判断网络拥塞等级，结合预先制定的丢包策略，有选择性地、主动丢弃数据包。避免了媒体数据中的关键、核心数据包被被动、随机丢弃，从而导致的无法解码，最终严重影响信宿端的解码质量的问题。从而实现根据网络拥塞等级，可以选择相对不重要，或者影响程度较小的数据，减少丢包对信宿端解码的影响，最大程度保证播放的流畅性，极大地改善终端用户的体验。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一种IPTV***中丢包处理方法一个实施例的流程图；

图2为本发明一种IPTV***中丢包处理方法又一个实施例的流程图

图3为本发明一种流媒体服务器一个实施例的结构示意图；

图4为本发明一种流媒体服务器又一个实施例的结构示意图；

图5为本发明一种IPTV***中丢包处理***一个实施例的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

流媒体服务器和客户端建立连接，客户端向流媒体服务器发送内容请求，流媒体服务器根据客户端的请求读取内容源的媒体数据。

请结合参看图1，本发明实施例提供了一种IPTV***中丢包处理方法，包括：

步骤102，解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，确认所述待发送媒体数据中数据包的重要等级。

流媒体服务器根据客户端的内容请求向内容源获取媒体数据，解析待发送媒体数据的NAL头和Slice头数据，根据待发送媒体数据的NAL头和Slice头数据确认该待发送媒体数据中各数据包的重要等级。

流媒体服务器将经过解析的媒体数据向客户端发送。可选的，流媒体服务器将获取的媒体数据承载在实时传输协议(Real-Time Transport Protocol，RTP)报文中，将承载有媒体数据的RTP报文向客户端发送。

步骤104，获取客户端根据接收媒体数据返回的结果信息，所述结果信息至少包括所述客户端接收所述媒体数据的数据丢失信息。

在流媒体服务器向客户端发送媒体数据时，由于传输网络可能存在网络拥塞，导致媒体数据的传输过程可能存在数据丢失，即丢包。即客户端接收的可能不是流媒体服务器发送的完整的媒体数据。客户端在接收媒体数据后，向流媒体服务器反馈结果信息。该结果信息中至少包括客户端在接收流媒体服务器发送的媒体数据的数据丢失信息。

可选的，该结果信息可以承载在实时传输控制协议(Real-Time Transport Control Protocol，RTCP)报文中，客户端将承载有该结果信息的RTCP报文信息向流媒体服务器发送。

步骤106，根据所述数据丢失信息确定当前传输网络的拥塞等级。

流媒体服务器根据客户端返回的数据丢失信息确定当前传输网络的状况。该传输网络的状况可以包括拥塞等级。

可选的，流媒体服务器根据结果信息反馈的时间段内的丢包数量确定当前传输网络的拥塞等级。其中，该结果信息反馈的时间段是指客户端接收流媒体服务器发送的媒体数据的持续时间段。例如：可以是客户端在持续接收RTP报文的时间段。可以是客户端在接收RTP报文的1毫秒-1000毫秒范围内的任意时间段、也可以是客户端在持续接收RTP报文最近1秒钟内、2秒钟内、3秒钟内、4秒钟内、5秒钟内等时间段内。

步骤108，根据所述传输网络的拥塞等级和所述数据包的重要等级，结合预先制定的丢包策略进行丢包处理。

流媒体服务器根据当前网络的拥塞等级和待发送媒体数据中各数据包的重要等级，结合预先制定的丢包策略进行丢包处理。

在IPTV***中，流媒体业务中的媒体数据传输由于传输网络的不稳定性，导致媒体数据传输过程丢包无法避免。本发明实施例通过判断网络拥塞等级和数据包的重要等级，结合预先制定的丢包策略，有选择性地、主动丢弃数据包。避免了媒体数据中的关键、核心数据包被被动、随机丢弃，从而导致的无法解码，最终严重影响信宿端的解码质量的问题。

可选的，在步骤104中，客户端根据接收的媒体数据，向流媒体服务器反馈结果信息，具体包括：客户端接收流媒体服务器通过RTP报文承载的媒体数据后，根据RTP报文中的标识字段，判断丢包情况。若判断产生丢包，则通过实时传输控制协议(Real-Time Transport Control Protocol，RTCP)报文向流媒体服务器反馈结果信息。该结果信息至少包括媒体数据丢失信息。其中该媒体数据丢失信息可以至少包括丢包数量。

请结合参看图2，本发明实施例提供了一种IPTV***中丢包处理方法，具体包括：

流媒体服务器和客户端建立连接。

步骤202，客户端向流媒体服务器发送媒体数据请求。

客户端向流媒体服务器发送媒体数据请求消息，请求流媒体服务器发送节目内容。

步骤204，流媒体服务器解析待发送媒体数据。

流媒体服务器解析待发送的媒体数据，并确认该待发送媒体数据中各数据包的重要等级。

流媒体服务器可以采用H.264编码标准来压缩媒体数据。为了大幅度的提高压缩效率，H.264采用了帧间预测技术，通过前后帧之间的比较预测，减少冗余数据。因此H.264将图像分成I帧、P帧、和B帧。其中I帧是帧内预测帧，可以通过自身的数据恢复图像，也是其他帧编码预测的参考频；P帧是前向预测帧，只参考I帧和其他P帧；而B帧是双向预测帧，参考前后的I帧和P帧。同时，在本发明实施例中，H.264标准采用网络提取层(Network Abstraction Layer，NAL)机制，将不同的数据分成不同的NAL类型，这样既可以减少数据的冗余度，又可以在一定程度上减少数据的相关性。通过H.264进行编码后的数据被封装到不同的单元之中，这些单元的重要性级别并不相同，丢失后对信宿端解码的影响程度也不一样。

在本发明实例中，流媒体服务器通过获取前端编码器发送的媒体数据，其中该媒体数据中的各数据包已经由前端编码器封装在不同的NAL类型中。流媒体服务器将获取的经过前端编码器编码和封装的媒体数据或媒体数据中各数据包。由于不同的NAL类型具有不同的作用，即不同NAL类型种的数据或数据包存在不同的重要性；同时各NAL类型中的不同Slice单元也封装了不同类型的帧数据，分别有I、B、P帧数据。因此流媒体服务器可以通过解析待发送给客户端的媒体数据的网络提取层NAL头和分片Slice头数据，确认该待发送的媒体数据中各数据包的重要等级。

具体的，流媒体服务器首先通过解析待发送的媒体数据得到该媒体数据中数据或数据包的类型。流媒体服务器通过解析待发送的媒体数据中网络提取层NAL头和分片Slice头数据，得到该媒体数据中数据或数据包的NAL类型和Slice类型。一般可以将媒体数据中的数据或数据包解析为如表1和表2的类型。

表1H.264标准中NAL单元类型

NAL type	NAL类型说明
		1	Coded slice of a non-IDR
5	Coded slice of an IDR picture
		6	Supplemental enhancement information
7	Sequence parameter set
		8	Picture parameter set

表2H.264标准中Slice类型

根据将媒体数据中的数据或数据包按照表1和表2的类型的划分，定义媒体数据中数据或数据包的重要等级。可以将待发送媒体数据中数据包分为核心级、重要级、次重要级以及普通级。具体可以参见表3的确认。

表3

重要等级	类型
		核心级	NAL type为5、7、8中的至少一种

重要级	NAL type为1、6以及Slice_type为2、4、7、9中的至少一种
		次重要级	Slice_type为0、3、5、8的单元中的至少一种
普通级	Slice_type为1、6的单元中的至少一种

步骤206，流媒体服务器根据客户端的媒体数据请求向客户端发送RTP报文。

流媒体服务器将经过解析的媒体数据向客户端发送。流媒体服务器将经过解析的媒体数据承载在实时传输协议(Real-Time Transport Protocol，RTP)报文中，将承载有媒体数据的RTP报文向客户端发送。

步骤208，客户端根据接收的RTP报文得到接收的结果信息。

具体的，在流媒体服务器向客户端发送媒体数据时，由于传输网络可能存在网络拥塞，导致媒体数据的传输过程可能存在丢包。即客户端接收的数据可能不是流媒体服务器发送的完整的媒体数据。

客户端接收流媒体服务器通过RTP报文承载的媒体数据后，根据RTP报文中的标识字段，判断丢包情况，得到至少包括丢包数量的结果信息。

步骤210，客户端向流媒体服务器发送RTCP报文。

客户端在接收媒体数据后，向流媒体服务器反馈结果信息。该结果信息中至少包括客户端在接收流媒体服务器发送的媒体数据的数据丢失信息。

具体的，该结果信息可以承载在RTCP报文中，客户端将承载有该结果信息的RTCP报文信息向流媒体服务器发送。

具体的，客户端根据RTP报文中的标识字段，判断数据丢失请求，即丢包情况，得到至少包括丢包数量的结果信息承载在RTCP报文中。客户端将承载丢包数量RTCP报文向流媒体服务器发送。

步骤212，流媒体服务器根据RTCP报文判断当前网络的拥塞等级。

流媒体服务器根据结果信息反馈的时间段内的丢包数量确定当前传输网络的拥塞等级。

流媒体服务器根据RTCP报文中的丢包信息判断当前网络的拥塞等级。

流媒体服务器根据RTCP报文反馈的时间段内的丢包数量确定当前传输网络的拥塞等级。该时间段指客户端在接收RTP报文的某个时间段。例如，可以是客户端在接收RTP1毫秒-1000毫秒范围内的任意时间段、也可以是客户端在接收RTP1秒钟、2秒钟、3秒钟、4秒钟、5秒钟等时间段内。

具体的，流媒体服务器根据RTCP报文中反馈的某一时间段的丢包数量判断当前网络的拥塞等级。为了能够尽可能真实地反映当前网络的拥塞等级，流媒体服务器可以根据RTCP报文中最近的一个时间段的丢包数量判断当前网络的拥塞等级。可选的，流媒体服务器可以根据RTCP报文反馈最近两秒钟累积的丢包数量确定当前网络的拥塞等级。其中，该最近两秒钟可以是指离反馈RTCP报文前，客户端两秒钟内接收RTP数据包的时间段。流媒体服务器根据RTCP报文反馈最近两秒钟累积的丢包数量确定当前网络的拥塞等级，可以如表4所示。

表4

RTCP报文反馈最近两秒累积丢包数量	当前网络拥塞等级
		0	健康级
大于0，不大于20个	次健康级
		大于20个，不大于50个	病态级
大于50个	严重病态级

即，若根据RTCP报文反馈的最近两秒钟累计丢包数量为零，则当前传输网络的拥塞等级为健康级；

若根据RTCP报文反馈的最近两秒钟累计丢包数量不为零，但小于20个，则当前传输网络的拥塞等级为次健康级；

若根据RTCP报文反馈的最近两秒钟累计丢包数量大于20个且小于50个，则当前传输网络的拥塞等级为病态级；

若根据RTCP报文反馈的最近两秒钟累计丢包数量大于50个，则当前传输网络的拥塞等级为严重病态级。

可选的，可以根据设置不同的时间段中不同的丢包数量级来确定当前网络的拥塞等级。

步骤214，流媒体服务器获取预先制定的丢包策略。

丢包策略指根据网络拥塞等级和数据重要等级决定如何进行丢包处理的策略。具体的，一般当网络拥塞等级低，即网络传输状况良好，则执行不丢弃任何数据的丢包策略；当网络拥塞等级变高，即网络传输状况变差时，可以选择丢弃数据重要等级低的数据或数据包；当网络拥塞等级高一直持续，即网络传输状况持续变差时，执行案数据重要等级从低到高继续丢弃数据或数据包的丢包策略，直至网络拥塞等级变低，即网络传输状况变好，则停止丢包。

需要说明的是，在本发明实施例中，步骤212与步骤214并没有时序上的限制，即步骤212与步骤214各步骤可以同时执行，也可以是先执行步骤212，再执行步骤214，也可以先执行步骤214，再执行步骤212。

步骤216，流媒体服务器根据当前传输网络的拥塞等级和媒体数据中数据包的重要等级，结合预先制定的丢包策略进行丢包处理。

由于媒体数据的传输是一个连续的过程，流媒体服务器发送一个RTP报文后，可以获得客户端根据接收该RTP报文返回的一个RTCP报文；流媒体服务器根据该RTCP报文中反馈的丢包信息确定当前传输网络的拥塞等级，从而根据当前传输网络的拥塞等级和待发送数据包的重要等级，结合预先制定的丢包策略执行丢包处理。

在本实施例中，流媒体服务器根据步骤212中确认的当前传输网络的拥塞等级，和步骤204中确认的媒体数据中各数据包的重要等级，结合步骤214中获得的预先制定的丢包策略进行丢包处理。

具体地，若所述当前网络的拥塞级别为健康级时，不丢弃数据包；

若所述当前网络的拥塞级别为次健康级时，可以选择丢弃普通级数据包；一旦当前网络的拥塞级别由次健康级转向健康级时，停止丢弃数据包；

若当前网络的拥塞级别为病态级时，先丢弃普通级数据包，并判断当前网络的拥塞级别是否已转为次健康级或健康级，若否，则丢弃次重要级数据包；

若当前网络的拥塞级别为严重病态级，先丢弃普通级数据包和次重要级数据包，并判断当前网络的拥塞级别是否已转为病态级、次健康级、健康级中的一种，若否，则丢弃核心级数据包。

步骤218，流媒体服务器将经过丢包处理的媒体数据向客户端发送。

本发明实施例流媒体服务器一方面流媒体服务器通过解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，确认所述待发送媒体数据中数据包的重要等级；另一方面通过实时接收客户端反馈的丢包信息，实时判断当前网络拥塞等级得到当前网络的传输状况；通过结合预先制定的丢包策略，有选择性地、主动丢弃数据包。从而实现根据网络拥塞等级，可以选择相对不重要，或者影响程度较小的数据，减少丢包对信宿端解码的影响，避免了媒体数据中的关键、核心数据包被被动、随机丢弃，从而导致的无法解码，最终严重影响信宿端的解码质量的问题，最大限度地保证客户端播放的流畅性，极大地改善终端用户的体验。

请结合参看图3，本发明实施例提供了一种流媒体服务器，包括：

分析模块302，用于解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，确认所述待发送媒体数据中数据包的重要等级。

获取模块304，用于获取客户端根据接收媒体数据返回的结果信息，该结果信息至少包括客户端接收该媒体数据的数据丢失信息。

确定模块306，用于根据获取模块302获取的该数据丢失信息确定当前传输网络的拥塞等级。

处理模块308，用于根据确定模块306确定的所述当前传输网络的拥塞等级和分析模块302确定的所述数据包的重要等级，结合预先制定的丢包策略进行丢包处理。

具体的，本发明实施例提供的流媒体服务器可以参照前述实施例提供的方法执行相应的流程，此处不再赘述。

请结合参看图4，本发明实施例提供了一种流媒体服务器，本发明实施例在前述实施例提供的流媒体服务器的基础上进一步改进。其中，分析模块302包括：解析单元402和数据包等级确认单元404。

解析单元402，用于解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，获得所述待发送媒体数据中数据包的类型。

具体的，解析单元402通过解析待发送的媒体数据得到该媒体数据中数据或数据包的类型。解析单元402通过解析待发送的媒体数据中网络提取层NAL头和分片Slice头数据，得到该媒体数据中数据或数据包的NAL类型和Slice类型。一般可以将媒体数据中的数据或数据包解析为如表1和表2的类型。

数据包等级确认单元404，用于根据所述待发送媒体数据中数据包的类型确定所述待发送媒体数据中数据包的重要等级。

数据包等级确认单元404根据解析单元402将媒体数据中的数据或数据包按照表1和表2的类型的划分，定义媒体数据中数据或数据包的重要等级。可以将待发送媒体数据中数据包确认为核心级、重要级、次重要级以及普通级。具体可以参见表3的确认。

请结合参看图5，本发明实施例提供了一种IPTV***中丢包处理***，包括：

客户端502，用于接收流媒体服务器504发送的媒体数据，并根据接收的所述媒体数据向流媒体服务器504发送结果信息；

流媒体服务器504，用于解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，确认所述待发送媒体数据中数据包的重要等级，获取客户端502返回的结果信息，所述结果信息至少包括所述客户端502接收所述媒体数据的数据丢失信息，根据所述数据丢失信息确定当前传输网络的拥塞等级，根据所述当前传输网络的拥塞等级和所述数据包的重要等级，结合预先制定的丢包策略进行丢包处理。

可选的，流媒体服务器504还用于将经过丢包处理的媒体数据向客户端502发送。

具体的，本发明实施例提供的IPTV***中丢包处理***中包括的流媒体服务器可以是前述实施例中提供的流媒体服务器。IPTV***中丢包处理***可以参照前述实施例提供的方法执行相应的流程，此处不再赘述。

本发明实施例在IPTV***中媒体数据的传输过程中，通过解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，确认所述待发送媒体数据中数据包的重要等级和判断网络拥塞等级，结合预先制定的丢包策略，有选择性地、主动丢弃数据包。避免了媒体数据中的关键、核心数据包被被动、随机丢弃，从而导致的无法解码，最终严重影响信宿端的解码质量的问题。，从而实现根据网络拥塞等级，可以选择相对不重要，或者影响程度较小的数据，减少丢包对信宿端解码的影响，最大程度保证播放的流畅性，极大地改善终端用户的体验。

本领域普通技术人员通过阅读本申请可知，上述方法中的全部或部分步骤也可以通过程序指令相关的硬件完成，该程序可以存储于计算机可读存储介质中，所述计算机可读存储介质如：ROM、RAM或光盘等。

综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种IPTV***中丢包处理方法，其特征在于，所述方法包括：

解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，确认所述待发送媒体数据中数据包的重要等级；

获取客户端根据接收媒体数据返回的结果信息，所述结果信息至少包括所述客户端接收所述媒体数据的数据丢失信息；

根据所述数据丢失信息确定当前传输网络的拥塞等级；

根据所述当前传输网络的拥塞等级和所述数据包的重要等级，结合预先制定的丢包策略进行丢包处理。

2.如权利要求1所述的方法，其特征在于，所述结果信息承载在实时传输控制协议RTCP报文中。

3.如权利要求1所述的方法，其特征在于，所述数据丢失信息至少包括丢包数量；所述根据所述数据丢失信息确定当前传输网络的拥塞等级包括：根据丢包数量确定当前传输网络的拥塞等级。

4.如权利要求3所述的方法，其特征在于，所述根据丢包数量确定当前传输网络的拥塞等级，包括：

根据结果信息反馈的时间段内的丢包数量确定当前传输网络的拥塞等级。

5.如权利要求4所述的方法，其特征在于，所述根据结果信息反馈的时间段内的丢包数量确定当前传输网络的拥塞等级，包括：

若根据RTCP报文反馈的最近两秒钟累计丢包数量为零，则当前传输网络的拥塞等级为健康级；

若根据RTCP报文反馈的最近两秒钟累计丢包数量不为零，但小于20，则当前传输网络的拥塞等级为次健康级；

若根据RTCP报文反馈的最近两秒钟累计丢包数量大于20且小于50，则当前传输网络的拥塞等级为病态级；

若根据RTCP报文反馈的最近两秒钟累计丢包数量大于50，则当前传输网络的拥塞等级为严重病态级。

6.如权利要求1-5所述的任一方法，其特征在于，所述在解析待发送媒体数据的网络提取层NAL头和分片Slice头数据后，还包括：

根据解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，获得所述待发送媒体数据中数据包的类型；

所述确认所述待发送媒体数据中数据包的重要等级，包括：根据所述待发送媒体数据中数据包的类型确定所述待发送媒体数据中数据包的重要等级。

7.如权利要求6所述的方法，其特征在于，所述根据所述待发送媒体数据中数据包的类型确定所述待发送媒体数据中数据包的重要等级，包括：

根据所述待发送媒体数据中数据包的类型将所述待发送媒体数据中数据包分为核心级、重要级、次重要级以及普通级。

8.如权利要求7所述的方法，其特征在于，根据所述当前传输网络的拥塞等级和所述数据包的重要等级，结合预先制定的丢包策略进行丢包处理，包括：

若所述当前网络的拥塞级别为健康级时，不丢弃数据包；

若所述当前网络的拥塞级别为次健康级时，选择丢弃普通级数据包；

若当前网络的拥塞级别为病态级时，先丢弃普通级数据包，并判断当前网络的拥塞级别是否已转为次健康级或健康级，若否，则丢弃次重要级数据包；

若当前网络的拥塞级别为严重病态级，先丢弃普通级数据包和次重要级数据包，并判断当前网络的拥塞级别是否已转为病态级、次健康级、健康级中的一种，若否，则丢弃核心级数据包。

9.一种流媒体服务器，其特征在于，所述流媒体服务器包括：

分析模块，用于解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，确认所述待发送媒体数据中数据包的重要等级；

获取模块，用于获取客户端根据接收媒体数据返回的结果信息，所述结果信息至少包括所述客户端接收所述媒体数据的数据丢失信息；

确定模块，用于根据所述获取模块获取的所述数据丢失信息确定当前传输网络的拥塞等级；

处理模块，用于根据所述确定模块确定的所述当前传输网络的拥塞等级和所述分析模块确定的所述数据包的重要等级，结合预先制定的丢包策略进行丢包处理。

10.如权利要求9所述的流媒体服务器，其特征在于，所述分析模块包括：

解析单元，用于解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，获得所述待发送媒体数据中数据包的类型；

数据包等级确认单元，用于根据所述待发送媒体数据中数据包的类型确定所述待发送媒体数据中数据包的重要等级。

11.一种IPTV***中丢包处理***，其特征在于，所述丢包处理***包括：

客户端，用于接收流媒体服务器发送的媒体数据，并根据接收的所述媒体数据向所述流媒体服务器发送结果信息；

所述流媒体服务器，用于解析待发送媒体数据的网络提取层NAL头和分片Slice头数据，确认所述待发送媒体数据中数据包的重要等级，获取所述客户端返回的结果信息，所述结果信息至少包括所述客户端接收所述媒体数据的数据丢失信息，根据所述数据丢失信息确定当前传输网络的拥塞等级，根据所述当前传输网络的拥塞等级和所述数据包的重要等级，结合预先制定的丢包策略进行丢包处理。

Images