CN104348577A - 改善云会议中的视频质量的重复包策略 - Google Patents

改善云会议中的视频质量的重复包策略 Download PDF

Info

Publication number
CN104348577A
CN104348577A CN201310330948.9A CN201310330948A CN104348577A CN 104348577 A CN104348577 A CN 104348577A CN 201310330948 A CN201310330948 A CN 201310330948A CN 104348577 A CN104348577 A CN 104348577A
Authority
CN
China
Prior art keywords
packet loss
repeat pattern
loss
packet
encoder
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.)
Granted
Application number
CN201310330948.9A
Other languages
English (en)
Other versions
CN104348577B (zh
Inventor
郭启行
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huihe Development Co ltd
Original Assignee
Polycom Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Polycom Inc filed Critical Polycom Inc
Priority to CN201310330948.9A priority Critical patent/CN104348577B/zh
Publication of CN104348577A publication Critical patent/CN104348577A/zh
Priority to HK15104790.7A priority patent/HK1204400A1/zh
Application granted granted Critical
Publication of CN104348577B publication Critical patent/CN104348577B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/15Conference systems

Abstract

一种改善云会议中的视频质量的重复包策略。提供了用于编码多媒体数据的多媒体编码设备(100)和方法(200)。多媒体编码设备(100)包括:用于从网络接收信道状态信息的信道状态接收器(105);用于根据信道状态信息确定重复模式的重复模式确定器(106);用于编码多媒体数据来产生多个编码包的编码器(101);用于根据确定的重复模式产生关键包的重复包的重复产生器(107),其中该关键包对于解码已编码的多媒体数据而言比其它包更重要。作为编码的结果,多媒体编码设备(100)输出编码包和重复包。

Description

改善云会议中的视频质量的重复包策略
技术领域
本发明涉及用于编码多媒体数据以便在网络上传输的多媒体编码设备和方法。
背景技术
视频会议系统已经日益开始使用诸如互联网之类的包交换网络,而不是诸如PSTN和ISDN之类的电路交换网络。使用包交换网络用于视频会议的一个问题是所有的包交换网络将经历某种程度的丢包。甚至适度的丢包都显著地损害视频质量。
为了克服丢包,一些视频会议装置采用了不同的包重传技术。例如,H.264/SVC解决方案使用一种重传方案。由于H.264/SVC涉及若干个时间层,重传方案仅仅重传基本层,以便不导致或导致较少的拥塞。但是重传会导致视频呈现显著的延迟。而且当信道条件进一步恶化时,不断增加的重传仍会不可避免地导致拥塞。
作为另一种解决方案,一些视频会议装置采用不同的包恢复技术。美国专利No.7,876,685中就描述了这样一种技术,所述专利被转让给Polycom公司,发明名称为“System and method for lost packet recovery with congestion avoidance(具有拥塞避免的用于丢包恢复的系统和方法)”,提交于2008年7月23日,其全部内容通过引用被并入本文。这样的技术在下文中可被称作“丢包恢复”或“LPR”。
当在有线网中被采用时,Polycom的视频LPR的确是有效的。但是在新兴的云视频会议的环境下,其性能能够被进一步改善。在云视频会议中,随机的和突发的丢包经常在下行链路中发生。它们通常是由互联网拥塞或接入网中的3G/无线链路丢失所导致的。在许多情况下,Polycom的视频LPR是最为有效的,一直到高达10%的丢包率,如果丢失超过视频LPR的保护能力,将会有视频伪像。在突发丢失的情况下事情变得更糟。同样地,如果它添加更多的冗余信息,视频LPR可能会涉及更多的延迟。
因此,需要提供改善的方法来克服上面提到的缺点或缺陷。
发明内容
本公开内容涉及用于编码多媒体数据的多媒体编码设备和方法。该方法与一些其它纠错机制合作来改善纠错能力而不引入任何额外的延迟,从而大大地改善多媒体数据的质量。
根据一个方面,提供了用于编码多媒体数据的多媒体编码设备。该多媒体编码设备包括:用于从网络接收信道状态信息的信道状态接收器;用于根据信道状态信息确定重复模式的重复模式确定器;用于编码多媒体数据来产生多个编码包的编码器;以及用于根据确定的重复模式产生关键包的重复包的重复产生器,其中该关键包对于解码已编码的多媒体数据而言比其它包更重要。
信道状态信息能够包括丢包率。
重复模式确定器能够根据丢包率为重复模式进一步确定重复率。
重复模式确定器能够进一步包括用于将丢包率与预先确定的阈值比较的比较器,如果丢包率不小于预先确定的阈值,重复模式确定器能够按照一个增加步长来增加当前的重复率,否则,重复模式确定器能够按照一个降低步长来降低当前的重复率。
重复模式确定器能够进一步包括用于将丢包率与预先确定的阈值比较的比较器,如果丢包率不小于预先确定的阈值,重复模式确定器确定应该产生重复包,否则,确定不需要重复。
信道状态信息能够进一步包括丢包涉及持续丢包还是突发丢包。
如果丢包涉及持续丢包,重复模式确定器能够设置重复块长度为1个包长,如果丢包涉及突发丢包,设置重复块长度不小于突发丢失窗口。
多媒体编码设备能够进一步包括纠错机制,其中预先确定的阈值是能够被该纠错机制纠正的最大丢包率。
关键包能够包括视频的I帧和/或纠错机制的纠错包。
纠错机制能够包括丢包恢复LPR机制,并且纠错包是LPR恢复包。
编码器能够在编码多媒体数据时减小编码器带宽,以便为重复带宽保存带宽。
编码器能够减小多媒体数据的一部分的编码器带宽,并且保持多媒体数据的其它部分的编码器带宽。
根据另一方面,提供了在网络上编码多媒体数据的方法。该方法包括:从网络接收信道状态信息;根据信道状态信息确定重复模式;编码多媒体数据来产生多个编码包;根据确定的重复模式产生关键包的重复包,其中该关键包对于解码已编码的多媒体数据来说比其它包更重要;以及在网络上输出编码包和重复包。
信道状态信息能够包括丢包率。
确定重复模式的步骤能够进一步包括根据丢包率为重复模式确定重复率。
确定重复率的步骤能够包括:将丢包率与预先确定的阈值比较;如果丢包率不小于预先确定的阈值,按照一个增加步长来增加当前的重复率,否则,按照一个降低步长来降低当前的重复率。例如,如果丢包率超出LPR保护范围,重复率被增加一个增加步长。相应地,如果丢包率在该范围内,重复率被降低一个降低步长。
确定重复率的步骤能够包括:将丢包率与预先确定的阈值比较;如果丢包率不小于预先确定的阈值,确定重复包应该被产生,否则,确定不需要重复。
信道状态信息能够进一步包括丢包涉及持续丢包还是突发丢包。
确定重复模式的步骤能够包括:如果丢包涉及持续丢包,设置重复块长度为1个包长;否则,如果丢包涉及突发丢包,设置重复块长度不小于突发丢失窗口。
预先确定的阈值能够是能够被网络中现存的纠错机制纠正的最大丢包率。
关键包能够包括视频的I帧和/或网络中现存的纠错机制的纠错包。
所述现存的纠错机制能够包括LPR机制,并且纠错包是LPR恢复包。
编码多媒体数据的步骤能够包括减小编码器带宽以便为重复带宽保存带宽。
减小编码器带宽的步骤能够包括减小多媒体数据的一部分的编码器带宽,并且保持多媒体数据的其它部分的编码器带宽。
本文描述的实施例能够采用重复包策略来将丢包降低到一些诸如视频LPR之类的纠错机制能够处理的范围并且该重复包策略不会涉及额外的延迟。特别地,重复包策略能够重复多媒体数据的一些重要的包。例如,视频LPR涉及对于恢复丢失的包很重要的恢复包。同样地,在视频中诸如I帧之类的关键帧能够被用来隐藏视频伪像。因此,这些包的重复在大型丢包的情况下改善了视频质量。
本文描述的至少一些实施例能够在MCU(多点控制单元)端中工作来为人员视频(People video)和内容视频(Content video)提供不同的策略,为不同的客户提供不同的策略。不同的策略会得到更好的用户体验。例如,在Polycom会议解决方案中有两种视频类型:人员和内容。在一些实施例中,内容视频仅仅被MCU转发,而不会在MCU端被解码/编码。对于发送内容视频的客户,MCU根据内容视频和人员视频花费的带宽开销来降低人员视频的带宽。
本文描述的实施例同样能够处理突发丢包。在突发丢包的情况下,可以涉及重复窗口或重复块。重复窗口或重复块的长度定义了有多少重复包被归组到一起,作为跟随相同数量的相应编码包的一个块被发送。1个包长的重复块长度意味着重复包将紧接着相应的编码包。n个包长的重复块长度意味着n个重复包的块跟随着n个编码包的相应块。能够限制窗口的最大值来避免过多的延迟。
总的来说,本文描述的配置易于实现且有效,不牵涉系统复杂度和延迟。此外,它能够处理突发丢包。
附图说明
被看作是本发明的主题将在说明书后面的权利要求书中加以特别地指出和清楚地要求保护。本发明前面提到的以及其它的特征和优点将在下文中结合附图进行的详细描述中变得清楚明白。
图1图示了根据本发明的一个实施例的多媒体编码设备的框图。
图2图示了根据本发明的一个实施例的多媒体编码方法的流程图。
图3图示了根据本发明的一个实施例的特定重复模式确定过程的流程图。
应当指出的是,本发明公开的实施例只是本文创新教导的许多有利的使用的示例。一般而言,本申请说明书中所做的陈述不必要限制任何不同的要求保护的发明。而且,一些陈述可以适用于一些发明的特征而不适用于其它。一般而言,除非另外指示,单数的元件可以是复数的而不失一般性,反之亦然。在附图中,相同的数字在若干视图中指代相同的部分。
具体实施方式
本发明的一些实施例将通过参考附图的方式如下详细描述。
图1图示了根据本发明的一个实施例的多媒体编码设备100的框图。图1图示了多媒体编码设备100的一种实现,该实现的变形同样是可能的。出于易于解释的目的,本发明在经由实时传输协议(RTP)网络传输视频数据的环境下加以描述。但是,本领域的技术人员知晓本发明完全不局限于视频数据和RTP网络。相反,本发明能够被应用于所有类型的多媒体数据和传输协议或网络。
如图1所示,多媒体编码设备100包括编码器101。编码器101编码多媒体数据来产生多个编码包。尽管编码器101能够单独产生包,但是它在图1中被图示为与某个打包器(比如图示的RTP发送器103)协同合作来产生包。在图示的示例中,编码器101可以是视频编码器。视频编码器可以是多种或多或少以常规方式运行的视频编码器中的任何一种。例如,视频编码器能够根据H.261、H.263、H.264、MPEG-2或MPEG-4视频压缩标准运行。可替换地,视频编码器能够根据多种专有视频编码技术中的任何一种来运行。
编码器101的输出(在本示例中为视频数据)能够被提供给多媒体编码设备100的可选加密模块102,它同样可以是多种已知类型中的任何一种。加密的视频数据(或未加密的视频数据,如果未使用加密的话)能够被提供给RTP发送器103,RTP发送器103同样可以是常规的。RTP发送器103从接收到的视频数据产生RTP包,并将产生的RTP包输出给多媒体编码设备100的LPR模块104。之后LPR模块104对RTP包重新打包来产生数据包和恢复包,正如下面将更详细地描述的。
LPR模块104能够执行丢包恢复功能。特别地,在每个保护周期期间,LPR模块104接收来自RTP发送器103的RTP包,对RTP包重新打包来产生数据包和恢复包。恢复包本质上涉及用于恢复包中某些丢失信息的冗余信息。多媒体数据的接收端能够使用接收到的数据包和恢复包来恢复丢失的包(如果有的话)。更长的保护周期提供更有效的包再生或更高的恢复能力,但是产生了更多的等待时间。为了保持等待时间可接受,LPR模块104具有最大恢复能力。也就是说,当丢失率不高于10%时它能够恢复丢失的包。同样由于保护周期的限制,LPR模块104对于突发丢包不能高效地工作。
信道状态接收器105被包含进来用于接收来自网络的诸如丢包和其它信道统计信息之类的信道状态信息。在RTP网络中,信道状态信息能够从RTCP(RTP控制协议)报告中被接收,包括RTCP SR/RR(发送器报告/接收器报告)报告。在一个实施例中,接收到的信道状态信息包括关于丢包涉及持续丢包还是突发丢包的信息。因此,信道状态接收器105能够指示出丢包涉及持续丢包还是突发丢包。
接收信道状态信息后,信道状态接收器105向多媒体编码设备100中的重复模式确定器106提供接收到的信道状态信息。重复模式确定器106根据信道状态信息确定重复模式,包括根据信道状态信息确定是否重复来自LPR模块104(或一些其它恢复机制)或RTP发送器103(如果不存在恢复机制)的包,以及为重复模式确定重复率和/或重复块长度。重复率可以是重复包数量与编码包数量的比率。
在一个实施例中,重复模式确定器106可以进一步包括用于将接收到的信道状态信息与预先确定的阈值比较的比较器(未示出在图1中)。信道状态信息能够包括丢包率,预先确定的阈值能够是在多媒体编码设备100中在不采用本文描述的重复解决方案的情况下能够被处理的最大丢包率。例如,如果采用LPR技术,预先确定的阈值可以是10%。本领域的技术人员知晓它可以是更小的值以便保证更好的视频质量。可替换地,预先确定的阈值对于其它类型的信道状态信息和/或对于其它包恢复机制和/或对于不同性能需求可以是其它值。重复模式确定器106能够确定设备的丢包恢复能力,并相应地确定阈值。如果比较器的比较结果是丢包率小于预先确定的阈值,重复模式确定器106按照一个降低步长来降低当前的重复率,否则,按照一个增加步长来增加当前的重复率。增加步长和降低步长可以是相同的或是不同的。一旦重复率达到最大或最小重复率,重复模式确定器106能够停止增加或降低重复率。在另一个实施例中,如果丢包率超过第二阈值,重复模式确定器106能够增加增加步长,以便更快地改善视频质量。第二阈值大于前文提到的预先确定的阈值。可替换地,如果比较器的比较结果是丢包率不小于预先确定的阈值,重复模式确定器106能够确定应该产生一个或更多重复包(例如确定重复率为预置的比率),否则,确定不需要重复(即确定重复率为0)。
在另一个实施例中,信道状态信息进一步包括丢包涉及持续丢包还是突发丢包的信息。重复模式或参数能够根据该信息被调整。例如,如果丢包涉及持续丢包,重复模式确定器106设置重复块长度为1个包长。如果丢包涉及突发丢包,重复模式确定器106设置重复块长度为不小于突发丢失窗口。重复块长度定义了有多少重复包被归组到一起,作为一个块跟随相同数量的相应编码包被发送。1个包长的重复块长度意味着重复包将紧接着相应的编码包。n个包长的重复块长度意味着n个重复包的块跟随着n个编码包的相应块。
在重复模式确定器106确定了重复模式和/或参数后,确定的重复模式和/或参数被提供给重复产生器107,该重复产生器107根据确定的重复模式和/或参数产生一个或更多关键包的一个或更多重复包,其中关键包是对于解码已编码的多媒体数据而言比其它包更重要的包。在一个实施例中,关键包包括视频的一个或更多I帧和/或设备中采用的纠错机制中的一个或更多纠错包。当采用LPR机制时,所述的一个或更多纠错包能够是一个或更多LPR恢复包。最后,重复产生器107能够向传输器提供编码包和重复包以便在网络上传输。由于重复产生器107仅仅重复一些包,因此接收端不需要进行复杂的变化来适应变化的多媒体包流。如果包被正确接收,其重复包能够被丢弃。如果包没有被正确接收或是被丢失,其重复包将被接收和采用。
在另一个实施例中,为了确保多媒体编码设备100的发送带宽是稳定的,编码器101能够在编码多媒体数据时减小编码器带宽,以便为重复带宽开销保存带宽。特别地,多媒体编码设备100的发送带宽能够等于带宽开销和编码器带宽之和。相应地,编码器101可以例如降低编码器帧率和/或编码率来降低编码器带宽,以便保证视频质量。通过这种方式,发送带宽不会由于一个或更多重复包而波动。
编码器101能够减小多媒体数据的一部分的编码器带宽,并且保持多媒体数据的其它部分的编码器带宽。例如,根据本发明的实施例的多媒体编码设备100能够部署在Polycom会议解决方案的MCU(多点控制单元)端。在Polycom会议解决方案中有两种视频类型:人员视频和内容视频。在一些实施例中,内容视频仅仅被MCU转发,而不会在MCU端被解码/编码。MCU端仅仅解码/编码人员视频。对于发送内容视频的客户,MCU按照内容视频和人员视频花费的带宽开销来降低人员视频的带宽。
图2图示了根据本发明一个实施例的多媒体编码方法200的流程图。如图2所示,多媒体编码方法开始于步骤210。在步骤220,该方法从网络接收诸如丢包和其它信道统计信息之类的信道状态信息。例如,信道状态信息能够经由RTP网络中的RTCP SR/RR报告被接收。接收到的信道状态信息能够进一步包括关于丢包涉及持续丢包还是突发丢包的信息。
在步骤230,该方法根据接收到的信道状态信息确定重复率。例如,根据接收到的丢包率来确定重复率。根据一个实施例,步骤230进一步包括将接收到的丢包率与预先确定的阈值比较,来确定接收的丢包率是否超过预先确定的阈值。预先确定的阈值可以是在没有本文描述的重复解决方案的情况下能够被处理的最大丢包率。在采用LPR技术的情况下,预先确定的阈值可以是10%。本领域的技术人员知晓它可以是更小的值以便保证更好的视频质量。可替换地,预先确定的阈值对于其它类型的信道状态信息和/或对于其它包恢复机制和/或对于不同性能需求可以是其它值。比较步骤能够进一步包括确定系统的丢包恢复能力和相应地确定阈值的子步骤。
根据一个实施例,步骤230进一步包括,如果比较结果是丢包率不小于预先确定的阈值,则按照一个增加步长来增加当前的重复率,否则,按照一个降低步长来降低当前的重复率。增加步长和降低步长可以是相同的或不同的。一旦重复率达到最大或最小重复率,步骤230能够停止增加或降低重复率。在另一个实施例中,如果丢包率超过第二阈值,步骤230增加增加步长以便更快地改善视频质量。第二阈值大于前述的预先确定的阈值。可替换地,如果比较结果是丢包率不小于预先确定的阈值,步骤230确定应该产生一个或更多重复包(例如以预置的重复率),否则,确定不需要重复(即确定重复率为0)。确定重复率的特定细节将在下文中参考图3来描述。
在步骤240,该方法检查接收到的信道状态信息来确定丢包涉及持续丢包还是突发丢包。如果它涉及持续丢包,该方法进行到步骤252,否则,该方法进行到步骤254。
在步骤252,重复块长度被设置为1个包长,而在步骤254,重复块长度被设置为不小于突发丢失窗口。
确定了重复率和重复块长度后,该方法进行编码多媒体数据来产生多个编码包。步骤260能够包括减小编码器带宽以便为重复带宽开销保存带宽的子步骤。编码步骤能够减小多媒体数据的一部分的编码器带宽,并且保持多媒体数据的其它部分的编码器带宽。
在步骤260产生编码包后,该方法进行步骤270,根据确定的重复模式(例如重复是否是必要的以及,如果是必要的,重复率和重复块长度)来产生一个或更多关键包的一个或更多重复包,其中关键包是对于解码已编码的多媒体数据而言比其它包更重要的包。关键包能够包括视频的一个或更多I帧和/或网络中现存的纠错机制的一个或更多纠错包。当LPR机制作为纠错机制被采用时,一个或更多纠错包能够是一个或更多LPR恢复包。
最后,在步骤280,该方法例如输出编码包和重复包给传输器以便在网络上传输。
根据一个实施例的多媒体编码设备和方法已在上文中参考其框图和流程图加以解释。现在将参考图3详细描述特定的重复模式确定过程。
图3图示了根据本发明一个实施例的特定的重复模式确定过程300的流程图。该流程图给出了如何确定重复模式的特定实现。但是本发明绝不能被限制在所述的特定实现中。
在步骤310,该过程开始于设置下列参数的默认值:Duplication_Rate,Duplication_Rate_Down_Step和Duplication_Rate_Up_Step。Duplication_Rate指重复包的比率。Duplication_Rate_Down_Step指一旦满足某个条件时用于降低重复率的步长。降低重复率的过程将在下面解释。Duplication_Rate_Up_Step指一旦满足某个条件时用于增加重复率的步长。增加重复率的过程同样将在下面解释。
在步骤320,将接收到的丢包率与预先确定的阈值比较来确定接收到的丢包率是否小于预先确定的阈值。在这个实现中,预先确定的阈值被设置为10%。如果步骤320的比较结果为“是”,即丢包率小于10%,该过程进行到步骤334。否则,该过程进行到步骤332。
在步骤332确定是否达到最大的重复率即Duplication_Rate_Max。例如,Duplication_Rate_Max可以被设置为100%。本领域的技术人员知晓Duplication_Rate_Max可以被设置为更大的值,100%仅仅是一个示例。一旦Duplication_Rate达到Duplication_Rate_Max,即步骤332的分支“是”,过程300停止增加Duplication_Rate并进行到步骤356。否则,如果Duplication_Rate还没有达到Duplication_Rate_Max,该过程进行到步骤342。
在步骤356,由于重复率达到Duplication_Rate_Max,并且丢包率不小于预先确定的阈值,步骤356会告诉编码器只编码关键帧(I帧)来隐藏丢包牵涉的伪像。然后过程300进行到步骤360。
在步骤342,执行Duplication_Rate_Up_Step判决来确定优选的Duplication_Rate_Up_Step。特别地,如果丢包率太大,Duplication_Rate_Up_Step应该被设置得更大。例如,在丢失率>15%的情况下,Duplication_Rate_Up_Step=30%,在15%>丢失率>12%的情况下,Duplication_Rate_Up_Step=20%。在该判决后,该过程进行到步骤352。
在步骤352,Duplication_Rate_Up_Step被添加到Duplication_Rate来更新Duplication_Rate。这个步骤是增加重复率的步骤。之后该过程进行到步骤360。
如上指示,如果步骤320的结果为“是”,该过程进行到步骤334。在步骤334确定是否达到最小重复率即Duplication_Rate_Min。例如,Duplication_Rate_Min可以被设置为0。如果“是”,该过程直接进行到步骤360。否则,如果还没有达到最小重复率,该过程进行步骤354。
在步骤354,Duplication_Rate_Down_Step从Duplication_Rate中被减去来更新Duplication_Rate。这个步骤是降低重复率的步骤。之后该过程进行到步骤360。
在步骤360,该过程检查接收到的信道状态信息来确定丢包涉及持续丢包还是突发丢包。如果它涉及持续丢包,该过程进行到步骤364,否则,该过程进行到步骤362。
在步骤364,Duplication_Block_Len(重复块长度)被设置为1个包长,而在步骤362,Duplication_Block_Len被设置为不小于Burst_Loss_Window(突发丢失窗口)。在设置重复块长度后,该过程进行到步骤374。步骤374根据确定的重复模式和/或参数计算源于重复的比特率开销,并相应地减小编码器比特率。同时,为一个或更多包产生一个或更多重复包。能够给予诸如I帧和恢复包之类的关键包更高的优先级。即关键包对于包重复而言具有更高的优先级。之后该过程进行到步骤380并以输出编码包和重复包结束。
在上文中参考附图和本发明的优选实施例详细描述了本发明。但是,本领域的技术人员知晓上文的详细描述仅仅为了解释本发明,而绝对不是将本发明的保护范围限制在上面的特定实施例中。本发明的范围仅仅由权利要求限定。在不偏离权利要求限定范围的情况下,本领域的技术人员能够对上述实施例做出任何修改和变形,这些修改和变形同样落入到本发明的保护范围之内。
在权利要求中,任何括号内的参考标记不能被解释为对权利要求的限制。词“包括”不排除权利要求中所列组件或步骤以外的组件或步骤的存在。组件前的词“一”或“一个”不排除有多个组件。
本发明既可以由包含不同组件的硬件来实现,也可以由适当编程的计算机实现。在列出若干装置的设备权利要求中,所述若干装置能够由一个或更多硬件实体实现。仅仅在相互不同的从属权利要求中记载一些措施这个事实并不意味着这些措施的组合不能够被有利地使用。

Claims (24)

1.一种用于编码多媒体数据的多媒体编码设备,包括:
用于从网络接收信道状态信息的信道状态接收器;
用于根据信道状态信息确定重复模式的重复模式确定器;
用于编码多媒体数据来产生多个编码包的编码器;以及
用于根据确定的重复模式产生关键包的重复包的重复产生器,其中该关键包对于解码已编码的多媒体数据而言比其它包更重要。
2.如权利要求1所述的多媒体编码设备,其中信道状态信息包括丢包率。
3.如权利要求2所述的多媒体编码设备,其中重复模式确定器进一步根据丢包率为重复模式确定重复率。
4.如权利要求3所述的多媒体编码设备,其中重复模式确定器进一步包括用于将丢包率与预先确定的阈值比较的比较器,
如果丢包率不小于预先确定的阈值,重复模式确定器按照一个增加步长来增加当前的重复率,
否则,重复模式确定器按照一个降低步长来降低当前的重复率。
5.如权利要求3所述的多媒体编码设备,其中重复模式确定器进一步包括用于将丢包率与预先确定的阈值比较的比较器,
如果丢包率不小于预先确定的阈值,重复模式确定器确定应该产生重复包,
否则,确定不需要重复。
6.如权利要求4所述的多媒体编码设备,其中信道状态信息进一步包括丢包涉及持续丢包还是突发丢包。
7.如权利要求6所述的多媒体编码设备,其中如果丢包涉及持续丢包,重复模式确定器设置重复块长度为1个包长,如果丢包涉及突发丢包,设置重复块长度不小于突发丢失窗口。
8.如权利要求4所述的多媒体编码设备,进一步包括纠错机制,其中预先确定的阈值是能够被该纠错机制纠正的最大丢包率。
9.如权利要求1至8的任一项所述的多媒体编码设备,其中关键包包括视频的I帧和/或纠错机制的纠错包。
10.如权利要求9所述的多媒体编码设备,其中纠错机制包括丢包恢复LPR机制,并且纠错包是LPR恢复包。
11.如权利要求1所述的多媒体编码设备,其中编码器在编码多媒体数据时减小编码器带宽,以便为重复包保存带宽。
12.如权利要求11所述的多媒体编码设备,其中编码器减小多媒体数据的一部分的编码器带宽,并且保持多媒体数据的其它部分的编码器带宽。
13.一种在网络上编码多媒体数据的方法,该方法包括:
接收来自网络的信道状态信息;
根据信道状态信息确定重复模式;
编码多媒体数据来产生多个编码包;
根据确定的重复模式产生关键包的重复包,其中该关键包对于解码已编码的多媒体数据而言比其它包更重要;以及
在网络上输出编码包和重复包。
14.如权利要求13所述的方法,其中信道状态信息包括丢包率。
15.如权利要求14所述的方法,其中确定重复模式进一步包括根据丢包率为重复模式确定重复率。
16.如权利要求15所述的方法,其中确定重复率包括:
将丢包率与预先确定的阈值比较;
如果丢包率不小于预先确定的阈值,按照一个增加步长来增加当前的重复率,
否则,按照一个降低步长来降低当前的重复率。
17.如权利要求15所述的方法,其中确定重复率包括:
将丢包率与预先确定的阈值比较;
如果丢包率不小于预先确定的阈值,确定应该产生重复包,
否则,确定不需要重复。
18.如权利要求16所述的方法,其中信道状态信息进一步包括丢包涉及持续丢包还是突发丢包。
19.如权利要求18所述的方法,其中确定重复模式包括:
如果丢包涉及持续丢包,设置重复块长度为1个包长;
否则,如果丢包涉及突发丢包,设置重复块长度不小于突发丢失窗口。
20.如权利要求16所述的方法,其中预先确定的阈值是能够被网络中现存的纠错机制纠正的最大丢包率。
21.如权利要求13至20的任一项所述的方法,其中关键包包括视频的I帧和/或网络中现存的纠错机制的纠错包。
22.如权利要求21所述的方法,其中现存的纠错机制包括丢包恢复LPR机制,并且纠错包是LPR恢复包。
23.如权利要求13所述的方法,其中编码多媒体数据包括减小编码器带宽以便为重复包保存带宽。
24.如权利要求23所述的方法,其中减小编码器带宽包括减小多媒体数据的一部分的编码器带宽,并保持多媒体数据的其它部分的编码器带宽。
CN201310330948.9A 2013-08-01 2013-08-01 用于编码多媒体数据的设备和方法 Active CN104348577B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201310330948.9A CN104348577B (zh) 2013-08-01 2013-08-01 用于编码多媒体数据的设备和方法
HK15104790.7A HK1204400A1 (zh) 2013-08-01 2015-05-20 改善云會議中的視頻質量的重複包策略

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201310330948.9A CN104348577B (zh) 2013-08-01 2013-08-01 用于编码多媒体数据的设备和方法

Publications (2)

Publication Number Publication Date
CN104348577A true CN104348577A (zh) 2015-02-11
CN104348577B CN104348577B (zh) 2019-01-08

Family

ID=52503484

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201310330948.9A Active CN104348577B (zh) 2013-08-01 2013-08-01 用于编码多媒体数据的设备和方法

Country Status (2)

Country Link
CN (1) CN104348577B (zh)
HK (1) HK1204400A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107800471A (zh) * 2017-11-17 2018-03-13 西安电子科技大学 基于多包接收的卫星随机接入拥塞控制方法
CN111788846A (zh) * 2018-02-15 2020-10-16 富士通株式会社 基站装置、终端装置、无线通信系统以及无线通信方法

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1407771A (zh) * 2001-06-26 2003-04-02 皇家菲利浦电子有限公司 具有分组重传请求的分组传输方法和相关的控制机制
WO2006060036A1 (en) * 2004-12-02 2006-06-08 Thomson Licensing Adaptive forward error correction
CN101222296A (zh) * 2008-01-31 2008-07-16 上海交通大学 上行蜂窝视频通信中自适应的传输方法及系统
EP2019522A2 (en) * 2007-07-23 2009-01-28 Stephen Botzko System and method for lost packet recovery with congestion avoidance
CN101505202A (zh) * 2009-03-16 2009-08-12 华中科技大学 一种流媒体传输自适应纠错方法
CN101753275A (zh) * 2008-12-15 2010-06-23 华为技术有限公司 重传视频报文的方法、装置及系统
CN101938770A (zh) * 2010-09-20 2011-01-05 南京邮电大学 基于网络信道状态的无线网络最大重传次数的优化方法

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1407771A (zh) * 2001-06-26 2003-04-02 皇家菲利浦电子有限公司 具有分组重传请求的分组传输方法和相关的控制机制
WO2006060036A1 (en) * 2004-12-02 2006-06-08 Thomson Licensing Adaptive forward error correction
US20080134005A1 (en) * 2004-12-02 2008-06-05 Izzat Hekmat Izzat Adaptive Forward Error Correction
EP2019522A2 (en) * 2007-07-23 2009-01-28 Stephen Botzko System and method for lost packet recovery with congestion avoidance
CN101364946A (zh) * 2007-07-23 2009-02-11 宝利通公司 避免丢失分组恢复中的拥塞的系统和方法
CN101222296A (zh) * 2008-01-31 2008-07-16 上海交通大学 上行蜂窝视频通信中自适应的传输方法及系统
CN101753275A (zh) * 2008-12-15 2010-06-23 华为技术有限公司 重传视频报文的方法、装置及系统
CN101505202A (zh) * 2009-03-16 2009-08-12 华中科技大学 一种流媒体传输自适应纠错方法
CN101938770A (zh) * 2010-09-20 2011-01-05 南京邮电大学 基于网络信道状态的无线网络最大重传次数的优化方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107800471A (zh) * 2017-11-17 2018-03-13 西安电子科技大学 基于多包接收的卫星随机接入拥塞控制方法
CN107800471B (zh) * 2017-11-17 2019-12-24 西安电子科技大学 基于多包接收的卫星随机接入拥塞控制方法
CN111788846A (zh) * 2018-02-15 2020-10-16 富士通株式会社 基站装置、终端装置、无线通信系统以及无线通信方法
CN111788846B (zh) * 2018-02-15 2023-12-01 富士通株式会社 基站装置、终端装置、无线通信系统

Also Published As

Publication number Publication date
CN104348577B (zh) 2019-01-08
HK1204400A1 (zh) 2015-11-13

Similar Documents

Publication Publication Date Title
US11489621B2 (en) Forward error correction for streaming data
KR101649374B1 (ko) 가속화된 처리율을 달성하는 시스템 및 방법
US8005028B2 (en) Data communication system, data transmitting device, data transmitting method, data receiving device, and data receiving method
CN101061659B (zh) 自适应前向纠错的方法和设备
US8004963B2 (en) Apparatus and method for packet redundancy and recovery
US20050013249A1 (en) Redundant packets for streaming video protection
JP5661693B2 (ja) 輻輳回避と共に損失パケット回復を行うシステム及び方法
US10320520B2 (en) Communication device, system and method
CN108174234A (zh) 一种流媒体传输方法及系统
RU2009116472A (ru) Динамическая модификация свойств видео
Holmer et al. Handling packet loss in WebRTC
CN108696491B (zh) 音频数据的发送处理方法与装置、接收处理方法与装置
CN113242155A (zh) 一种数据包丢包的恢复方法、系统及计算机可读存储介质
CN111935485A (zh) 一种rs码前向纠错方法及装置
KR20130086552A (ko) 점진 열화 순방향 오류 정정 방법 및 이를 수행하는 장치
US8799749B2 (en) Ad-hoc multimedia group communication terminal robust to packet loss and method of operating the same
CN104348577A (zh) 改善云会议中的视频质量的重复包策略
Argyropoulos et al. Robust transmission of multi-view video streams using flexible macroblock ordering and systematic LT codes
CN103152126B (zh) 基于前向纠错保护编码的数据封装方法和装置
KR101953580B1 (ko) 영상회의 시스템에서 데이터 송수신 장치 및 방법
Huang et al. Optimization of source and channel coding for voice over IP
Yu et al. Performance analysis of the efficacy of packet-level FEC in improving video transport over networks
Díaz et al. Enhancement of Pro-MPEG COP3 codes and application to layer-aware FEC protection of two-layered video transmission
CN113542685B (zh) 一种基于可靠udp的实时超高清视频传输方法
Xu et al. Development of a network adaptive H. 264/AVC medical video transmission system

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1204400

Country of ref document: HK

GR01 Patent grant
GR01 Patent grant
REG Reference to a national code

Ref country code: HK

Ref legal event code: WD

Ref document number: 1204400

Country of ref document: HK

TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20231017

Address after: Texas, USA

Patentee after: Huihe Development Co.,Ltd.

Address before: California, USA

Patentee before: POLYCOM Inc.