CN114257836A - 一种机顶盒及丢包处理方法 - Google Patents

一种机顶盒及丢包处理方法 Download PDF

Info

Publication number
CN114257836A
CN114257836A CN202111554979.3A CN202111554979A CN114257836A CN 114257836 A CN114257836 A CN 114257836A CN 202111554979 A CN202111554979 A CN 202111554979A CN 114257836 A CN114257836 A CN 114257836A
Authority
CN
China
Prior art keywords
packet loss
packet
rtp
buffer
rtp 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
Application number
CN202111554979.3A
Other languages
English (en)
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.)
Hisense Broadband Multimedia Technology Co Ltd
Original Assignee
Hisense Broadband Multimedia Technology Co Ltd
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 Hisense Broadband Multimedia Technology Co Ltd filed Critical Hisense Broadband Multimedia Technology Co Ltd
Priority to CN202111554979.3A priority Critical patent/CN114257836A/zh
Publication of CN114257836A publication Critical patent/CN114257836A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23106Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/643Communication protocols
    • H04N21/6437Real-time Transport Protocol [RTP]

Abstract

本申请提供的一种机顶盒及丢包处理方法中,机顶盒包括第一网络端口、缓冲区和处理器,将RTP包从缓冲区读取至缓存队列中,然后根据所述RTP包的传输码率调整丢包请求间隔和缓存速率,并且在达到调整后相应丢包请求间隔且存在丢包时发出丢包重传请求,以调整后不同所述缓存速率将RTP包从缓冲区读取至缓存队列中。本申请中实时获取RTP包的传输码率,并根据码率动态调整丢包请求间隔,实现在早期发送丢包请求,保证丢包请求的及时性,同时根据码率动态调整缓存速率,及时将服务器重传回来的RTP数据从缓冲区读取至缓存队列中,保证数据获取的及时性,进而保证数据完整性,进而保证播放的流畅性,提高播放质量。

Description

一种机顶盒及丢包处理方法
技术领域
本申请涉及网络通信技术领域,尤其涉及一种机顶盒及丢包处理方法。
背景技术
在播放节目时,机顶盒向服务器发出RTSP(Real Time Stresming Protocol,实时流协议)请求,服务器在接到请求后,将音频数据和视频数据复合成TS(Transport Stresm,传输流)数据流,然后加上RTP(Real-time Transport Protocol,实时传输协议)协议头,最终以RTP包的形式发送至机顶盒端。
服务器端在向机顶盒发送RTP包的过程中可能会出现丢包现象,丢包请求不及时时,无法收到服务器的应答包,导致视频播放卡顿,无法流畅播放视频。
发明内容
本申请提供了一种机顶盒及丢包处理方法,及时发出丢包请求,提高播放质量。
第一方面,本申请提供的一种机顶盒,包括:
第一网络端口,用于连接服务器,以实现服务器端与机顶盒端传输RTP包;
缓冲区,与所述第一网络端口连接,用于存储所述RTP包;
处理器,与所述缓冲区连接,用于将RTP包从缓冲区读取至缓存队列中,然后根据所述RTP包的传输码率调整丢包请求间隔,并且在达到相应丢包请求间隔且存在丢包时发出丢包重传请求。
第二方面,本申请提供的一种丢包处理方法,用于机顶盒,所述方法包括:
从缓冲区读取RTP包,并解析所述RTP包的序号;
若所述RTP包的序号为0,则传输至音视频解码芯片;
从缓冲区读取另一RTP包,并存储至缓存队列中;
判断是否达到第一丢包请求间隔,并且在达到所述第一丢包请求间隔且存在丢包时发出丢包重传请求;
在得到所述RTP包的传输码率后,在传输数据为第一码率时,判断是否达到第二丢包请求间隔,并且在达到所述第二丢包请求间隔且存在丢包时发出丢包重传请求;
在传输数据为第二码率时,判断是否达到第三丢包请求间隔,并且在达到所述第三丢包请求间隔且存在丢包时发出丢包重传请求。
本申请提供的一种机顶盒及丢包处理方法中,机顶盒包括第一网络端口、缓冲区和处理器,第一网络端口连接服务器和缓冲区,缓冲区用于存储服务器端发送的RTP包,将RTP包从缓冲区读取至缓存队列中,然后根据所述RTP包的传输码率调整丢包请求间隔和缓存速率,并且在达到调整后相应丢包请求间隔且存在丢包时发出丢包重传请求,以调整后不同所述缓存速率将RTP包从缓冲区读取至缓存队列中。本申请中实时获取RTP包的传输码率,并根据码率动态调整丢包请求间隔,实现在早期发送丢包请求,保证丢包请求的及时性,同时根据码率动态调整缓存速率,及时将服务器重传回来的RTP数据从缓冲区读取至缓存队列中,保证数据获取的及时性,进而保证数据完整性,进而保证播放的流畅性,提高播放质量。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的机顶盒的使用场景图;
图2为本申请实施例提供的一种丢包处理方法的流程图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
图1为本申请实施例提供的机顶盒的使用场景图。如图1所示,用户可通过机顶盒控制装置101操作机顶盒100、通过显示设备遥控装置201操作显示设备200。机顶盒控制装置101和显示设备遥控装置201可以是遥控器,遥控器和机顶盒100的通信包括红外协议通信或蓝牙协议通信,及其他短距离通信方式,通过无线或有线方式来控,遥控器和显示设备200的通信包括红外协议通信或蓝牙协议通信,及其他短距离通信方式,通过无线或有线方式来控制显示设备200。
机顶盒100和显示设备200分别还与服务器300进行数据通信。可允许机顶盒100和显示设备200通过局域网(LAN)、无线局域网(WLAN)和其他网络进行通信连接。服务器300可以向显示设备200提供各种内容和互动。服务器400可以是一个集群,也可以是多个集群,可以包括一类或多类服务器。
机顶盒100可以接入网络并进行页面信息浏览、音视频播放等交互功能,除了直播功能,还可以给用户提供点播、会看等服务、暂停、快进、快退等时移功能。
流媒体播放器主要负责播放的控制、流媒体数据的传输与缓存、解码和显示等任务。
流媒体播放器在收到浏览器获取的流媒体网络地址后,与流媒体服务器建立RSTP会话,通过会话的发送与接收来控制流媒体的播放;数据接收到后,先对流媒体数据进行缓存,并根据数据包的序号进行排序,以实现正常流畅的播放;具体地,先对缓存后的数据进行解析,将音频和视频数据流分开,然后根据音频和视频格式传输到相应的解码器,对其进行解码播放。
在播放节目时,机顶盒向服务器发出RTSP(Real Time Stresming Protocol,实时流协议)请求,服务器在接到请求后,将音频数据和视频数据复合成TS(Transport Stresm,传输流)数据流,然后加上RTP(Real-time Transport Protocol,实时传输协议)协议头,最终以RTP包的形式发送至机顶盒端。
其中RTP协议为实时传输协议,其可以承载TS数据流,保证数据高效、实时传输。
RTSP(Real Time Stresming Protocol,实时流协议)用来控制实时数据的发送,RTSP可控制多个数据发送会话。在RTSP会话期间,可打开或关闭多个对服务器的可靠传输连接,以发出RTSP请求。
本申请实施例中的机顶盒包括第一网络端口,通过第一网络端口连接服务器,以实现服务器端向机顶盒端传输RTP包。由于数据传输过程具有不稳定性和不确定性,从服务器端向机顶盒端传输RTP包的过程中可能会出现丢包现象,如果发送丢包请求不及时,或不能快速接收到服务器端重新传回的RTP包,会导致在播放时出现卡村,影响播放质量。
机顶盒还包括缓冲区;网络中对数据的传输是分段异步传输,经过不同的路径到达终端机顶盒时并不能保证其顺序,为了能够快速并且正确的播放视频,对于接收到的流媒体数据,需先将其缓存起来,并根据TRP的序列号进行排序。在发送数据时,每个RTP包将前一个包的序列号加1作为自己的序列号,接收端在接收到RTP包后,可以根据序列号进行排序。本申请实施例中的缓冲区就是用来缓存服务器端传输过来的RTP包。
本申请实施例中机顶盒的处理器,主要为CPU处理芯片,其从缓冲区中读取RTP包,并将RTP包存储至缓存队列中,然后再从缓存队列中读取RTP包,将从缓存队列中读取出来的RTP包传输至音视频解码芯片上,因此机顶盒还包括第二接口,通过第二接口将缓存队列中的RTP包传输至音视频解码芯片上;音视频解码芯片对RTP包进行解码后播放。
为了使本发明实施例的目的、技术方案和优点更加清楚,下面结合附图2和具体实施例对本发明实施例执行详细描述。
如图2所示,本申请实施例中在处理丢包时包括:
S110:从缓冲区读取第一RTP包,并传输至音视频解码芯片。
第一RTP包的序号为0,即RTP0,将RTP0传输至音视频解码芯片,解码后进行播放。
S120:从缓冲区读取一RTP包,并将该RTP包缓存至缓存队列。
缓冲区的RTP包为排好序的RTP包,本申请实施例中没有从缓冲区中将RTP包读取后,直接传输至音视频解码芯片,而是将缓冲区的RTP包先缓存至缓存队列,从缓存队列中读取RTP包并传输至音视频解码芯片。本申请实施例将缓冲区的RTP包对等地缓存至缓存队列中。
这样可以在从缓冲区的RTP包转移至缓存队列时,及时发现是否有丢包现象。
具体地在将RTP包从缓冲区读取至缓存队列后,立即启动判断是否达到当前丢包请求间隔,如果达到则检查是都有丢包,如果有丢包,则向服务器端发送丢包重传请求。本申请中将缓冲区的RTP包遍历一次到缓存队列中,可以及时发现是否有丢包现象,并及时发出丢包重传请求。
S130:判断是否达到丢包请求间隔。
本申请中以一定的丢包请求间隔规律性地向服务器发出丢包重传请求,使服务器可以规律性地重新传回丢失的RTP包,保证数据传输工作的稳序进行。
本申请实施例中将RTP包从缓冲区转移至缓存队列后,立即启动判断是否达到丢包请求间隔。
如果达到丢包请求间隔,则S141:检查是否有丢包,有丢包时发送丢包重传请求。
如果没有达到丢包请求间隔,则S142:不检查是否有丢包,即如果没有达到丢包请求间隔,则不作处理。
S150:是否可以计算出码率。
由于码率可以衡量传输数据量,码率即单位时间内传输的数据量,码率在动态发生变化,因此本申请实施例中根据动态变化的码率,实时调整参数。
具体地,对RTP包进行解析,解析时去掉RTP的头部信息,得到TS流
S160:根据码率调整缓存速率和丢包请求间隔。
缓存速率指的是从缓冲区读取至缓存队列中的速率。
当码率变大时,说明此时传输数据量增大,需适时增加缓存速率及减小丢包请求间隔。
S170:判断是否达到调整后的丢包请求间隔。
本申请实施例中一旦调整丢包请求间隔,就立即启动判断是否达到调整后的丢包请求间隔。
如果达到丢包请求间隔,则S181:检查是否有丢包,有丢包时发送丢包重传请求。
如果没有达到丢包请求间隔,则S182:不检查是否有丢包,即如果没有达到丢包请求间隔,则不作处理。
本申请实施例中根据传输数据的码率动态调整丢包请求间隔,而非以固定的丢包请求间隔进行丢包检查及发出丢包请求,这样可以尽早发现丢包并尽早发出丢包重传请求。
S190:判断缓存队列中是否存在与上一RTP包连续的RTP包。
如果存在,则S200:从缓存队列中读取RTP包,并从缓冲区读取一个RTP包,继续S120循环。
如果不存在,则S210:从缓冲区读取RTP包,并判断是否与上一RTP包连续。
如果连续,则S220:将该RTP包传输至音视频解码芯片。解码后进行播放。
如果不连续,则S230:将该RTP包缓存至缓存队列中,并继续S120循环。
从上述可以看出,在一些实施例中,首先从缓冲区读取RTP包,并解析所述RTP包的序号;
若所述RTP包的序号为0,则传输至音视频解码芯片;
从缓冲区读取另一RTP包,并存储至缓存队列中;
判断是否达到第一丢包请求间隔,若达到所述第一丢包请求间隔且存在丢包时,发出丢包重传请求;
根据所述缓存队列中的RTP包计算所述RTP包的传输码率,并将丢包请求间隔从第一丢包请求间隔调整为第二丢包请求间隔;
判断是否达到第二丢包请求间隔,若达到所述第二丢包请求间隔且存在丢包时,发出丢包重传请求。
在一些实施例中,首先从缓冲区读取RTP包,并解析所述RTP包的序号;
若所述RTP包的序号为0,则传输至音视频解码芯片;
从缓冲区读取另一RTP包,并存储至缓存队列中;
判断是否达到第一丢包请求间隔,若达到所述第一丢包请求间隔且存在丢包时,发出丢包重传请求;
根据所述缓存队列中的RTP包没有得到RTP包的传输码率时,再次判断是否达到第一丢包请求间隔,若达到所述第一丢包请求间隔且存在丢包时,发出丢包重传请求。
在一些实施例中,从缓冲区读取RTP包,并解析所述RTP包的序号;
若所述RTP包的序号为0,则传输至音视频解码芯片;
从缓冲区以第一缓存速率读取另一RTP包,并存储至缓存队列中;
根据所述缓存队列中的RTP包计算所述RTP包的传输码率,并将缓存速率从第一缓存速率调整为第二缓存速率。
在一些实施例中,从缓冲区读取RTP包,并解析所述RTP包的序号;
若所述RTP包的序号为0,则传输至音视频解码芯片;从缓冲区以第一缓存速率读取另一RTP包,并存储至缓存队列中;
根据所述缓存队列中的RTP包未计算出所述RTP包的传输码率,仍以第一缓存速率从缓冲区读取RTP包。
为了使本申请实施例提供的技术方案更清晰、更突出,下面以具体实施例来描述上述方案。
机顶盒向视频服务器请求音视频数据。视频服务器基于机顶盒的请求,依次向机顶盒发送携带音视频数据的50个RTP包,分别记为RTP0~RTP49。每一个RTP包中包括对应的序号,分别为0~49。
若机顶盒接收到RTP0,获取该RTP0的序号0,可知该RTP0为第一个RTP包。机顶盒解析RTP0,记录当前解析的RTP包的序号N=0。
然后从缓冲区读取RTP1,并将RTP放在缓存队列中。此时缓存速率为第一缓存速率,可以理解的是,之所以成为第一缓存速率是为了便于与后续的缓存速率进行区分,并不作限定。
缓存队列
RTP1
判断是否达到第一丢包请求间隔,可以理解的是,之所以成为第一丢包请求间隔是为了便于与后续的丢包请求间隔进行区分,并不作限定。如果达到第一丢包请求间隔,则检查是否有丢包,如果有丢包时向服务器端发出丢包重传请求;如果没有达到第一丢包请求间隔,则不作处理,继续后面的流程。
对缓存队列中的RTP1进行解析,判断是否可以得到码率数值,如果得到,则根据码率调整丢包请求间隔,如果得不到,则不作处理,继续后面的流程。一般情形下,对RTP1进行解析由于数据太少,无法得到码率数值。此时的丢包请求间隔仍然为第一丢包请求间隔。
则再次判断是否达到第一丢包请求间隔,如果达到第一丢包请求间隔,则检查是否有丢包,如果有丢包时向服务器端发出丢包重传请求;如果没有达到第二丢包请求间隔,则不作处理,继续后面的流程。
判断缓存队列中是否有与RTP0连续的包,即RTP1,如果存在则从缓存队列中读取RTP1,并传输至音视频解码芯片,解码后进行播放,并从缓冲区读取RTP2至缓存队列中。如果不存在,则从缓冲区读取RTP包,并判断是否与RTP0连续,如果连续,则读取,如果不连续,则将其放在缓存队列中。
本申请实施例中,将RTP1从缓存队列中读走,并从缓冲区读取RTP2至缓存队列中。
然后重复上述步骤,对RTP2进行上述RTP1的操作。
在将RTP2放在缓存队列中后,判断是否达到第一丢包请求间隔,可以理解的是,之所以成为第一丢包请求间隔是为了便于与后续的丢包请求间隔进行区分,并不作限定。如果达到第一丢包请求间隔,则检查是否有丢包,如果有丢包时向服务器端发出丢包重传请求;如果没有达到第一丢包请求间隔,则不作处理,继续后面的流程。
对缓存队列中的RTP1和RTP2进行解析,判断是否可以得到码率数值,如果得到,则根据码率调整丢包请求间隔,如果得不到,则不作处理,继续后面的流程。一般情形下,对RTP1和RTP2进行解析由于数据太少,无法得到码率数值。此时的丢包请求间隔仍然为第一丢包请求间隔。
则再次判断是否达到第一丢包请求间隔,如果达到第一丢包请求间隔,则检查是否有丢包,如果有丢包时向服务器端发出丢包重传请求;如果没有达到第二丢包请求间隔,则不作处理,继续后面的流程。
判断缓存队列中是否有与RTP1连续的包,即RTP1,如果存在则从缓存队列中读取RTP1,并传输至音视频解码芯片,解码后进行播放,并从缓冲区读取RTP3至缓存队列中。如果不存在,则从缓冲区读取RTP包,并判断是否与RTP1连续,如果连续,则读取,如果不连续,则将其放在缓存队列中。
本申请实施例中,将RTP2从缓存队列中读走,并从缓冲区读取RTP3至缓存队列中。
此时缓存队列为:
缓存队列
RTP1
RTP2
本申请实施例中以RTP20为丢包,其余包为连续包为例;且以缓存队列中存在10个RTP包时可以得到码率为例,进行下面的说明。
本申请实施例中RTP0-RTP8如同上述RTP1一样的操作步骤,不再赘述。此时缓存队列为:
缓存队列
RTP1
RTP2
RTP3
……
RTP8
从缓冲区读取RTP9,并将RTP9放在缓存队列中,根据缓存队列中的RTP0-RTP9计算码率,然后根据码率将第一缓存速率调整为第二缓存速率,第一丢包请求间隔调整为第二丢包请求间隔。在本申请实施例中,第二缓存速率大于第一缓存速率,第二丢包请求间隔小于第一丢包请求间隔。实现在早期发送丢包请求,且在短期内接收服务器重传的RTP包,保证数据完整性
本申请实施例中提供的方案尤其适用于高码率的节目数据传输,如分辨率为4K的节目,这类节目的数量尤其大,出现丢包的概率升高,根据码率动态调整缓存速率和丢包请求间隔,可以保证高码率节目的数据请求及时性和完整性。
然后判断是否达到调整后的第二丢包请求间隔,如果达到第二丢包请求间隔,则检查是否有丢包,如果有丢包时向服务器端发出丢包重传请求;如果没有达到第二丢包请求间隔,则不作处理,继续后面的流程。
具体地,在将RTP10放在缓存队列中后,判断是否达到第二丢包请求间隔,可以理解的是,之所以成为第二丢包请求间隔是为了便于与后续的丢包请求间隔进行区分,并不作限定。如果达到第二丢包请求间隔,则检查是否有丢包,如果有丢包时向服务器端发出丢包重传请求;如果没有达到第二丢包请求间隔,则不作处理,继续后面的流程。
对缓存队列中的RTP1-RTP10进行解析,判断是否可以得到码率数值,如果得到,则根据码率调整丢包请求间隔,如果得不到,则不作处理,继续后面的流程。本申请实施例以得到码率后,将第二丢包请求间隔调整为第三丢包请求间隔,将第二缓存速率调整为第三缓存速率为例。
则再次判断是否达到第三丢包请求间隔,如果达到第三丢包请求间隔,则检查是否有丢包,如果有丢包时向服务器端发出丢包重传请求;如果没有达到第三丢包请求间隔,则不作处理,继续后面的流程。
判断缓存队列中是否有与上一RTP连续的包,如果存在则从缓存队列中读取,并传输至音视频解码芯片,解码后进行播放,并从缓冲区继续读取一个RTP包缓存队列中。如果不存在,则从缓冲区读取RTP包,并判断是否与上一RTP包连续,如果连续,则读取,如果不连续,则将其放在缓存队列中。
本申请实施例中,在发出丢包重传请求后,服务器端将RTP包重新发送至缓冲区,因此在丢包后,从缓冲区有可能会读取到丢失的RTP包,因此,如果缓存队列中没有读取到与上一RTP包连续的包,则从缓冲区读取一RTP包,并判断该RTP包是否与上一RTP包连续,如果是,则读取该RTP包并传输至音视频解码芯片,如果不是,则将其放在缓存队列中。
此时为首次得出码率,后续在处理过程中,码率会发生实时变化,则缓存速率和丢包请求间隔也随之动态调整。
其中以下述为例:在读取RTP6后,判断缓存队列中是否存在RTP7。如果存在RTP7则从缓存队列中读取RTP7,并将RTP8从缓冲区读取至缓存队列中。
本申请实施例中以RTP20为丢包为例进行示例性说明。此时缓存队列为:
缓存队列
RTP1
RTP2
RTP3
RTP4
RTP5
……
RTP19
RTP21
在读取RTP19后,判断缓存队列中是否存在RTP20,判断发现没有RTP20,则从缓冲区中读取RTP包,如果该RTP包为RTP20,则读取RTP20,并传输至音视频解码芯片,解码后播放。
如果该RTP包不是RTP20,则将该RTP包放在缓存队列中。
从上述可以看出,本申请实施例中,在将RTP包从缓冲区读取至缓存队列后,立即启动判断是否达到当前丢包请求间隔,如果达到则检查是都有丢包,如果有丢包,则向服务器端发送丢包重传请求。本申请中将缓冲区的RTP包遍历一次到缓存队列中,可以及时发现是否有丢包现象,并及时发出丢包重传请求。
本申请中,及时判断是否可以得到传输数据的码率,并根据码率调整缓存速率和丢包请求间隔,随着码率的增大,则增大缓存速率,减小丢包请求间隔。减小丢包请求间隔可以尽早发现丢包并发送丢包重传请求,在窗口期能够最大次数地反馈丢掉的数据包,增大缓存速率可以增加从缓冲区至缓存队列的RTP包的数量,在短期内接收服务器重传的RTP包,保证数据完整性,进而保证播放的流畅性,提高播放质量。
本申请中以一定的丢包请求间隔规律性地向服务器发出丢包重传请求,使服务器可以规律性地重新传回丢失的RTP包,保证数据传输工作的稳序进行。
本申请实施例中提供的方案尤其适用于高码率的节目数据传输,如分辨率为4K的节目,这类节目的数量量尤其大,出现丢包的概率升高,根据码率动态调整缓存速率和丢包请求间隔,可以保证高码率节目的数据请求及时性和完整性。
本申请提供的一种机顶盒及丢包处理方法中,机顶盒包括第一网络端口、缓冲区和处理器,第一网络端口连接服务器和缓冲区,缓冲区用于存储服务器端发送的RTP包,将RTP包从缓冲区读取至缓存队列中,然后根据所述RTP包的传输码率调整丢包请求间隔和缓存速率,并且在达到调整后相应丢包请求间隔且存在丢包时发出丢包重传请求,以调整后不同所述缓存速率将RTP包从缓冲区读取至缓存队列中。本申请中实时获取RTP包的传输码率,并根据码率动态调整丢包请求间隔,实现在早期发送丢包请求,保证丢包请求的及时性,同时根据码率动态调整缓存速率,及时将服务器重传回来的RTP数据从缓冲区读取至缓存队列中,保证数据获取的及时性,进而保证数据完整性,进而保证播放的流畅性,提高播放质量。
最后应说明的是:以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

1.一种机顶盒,其特征在于,包括:
第一网络端口,用于连接服务器,以实现服务器端与机顶盒端传输RTP包;
缓冲区,与所述第一网络端口连接,用于存储所述RTP包;
处理器,与所述缓冲区连接,用于将RTP包从缓冲区读取至缓存队列中,然后根据所述RTP包的传输码率调整丢包请求间隔和缓存速率,并且在达到调整后相应丢包请求间隔且存在丢包时发出丢包重传请求,以调整后不同所述缓存速率将所述RTP包从缓冲区读取至缓存队列中。
2.根据权利要求1所述的机顶盒,其特征在于,还包括:
第二网络端口,连接所述处理器,以实现处理器端与音视频解码芯片端传输RTP包;
所述音视频解码芯片,通过所述第二网络端口与所述处理器连接,用于接收所述RTP包并解码所述RTP包。
3.根据权利要求1所述的机顶盒,其特征在于,所述处理器还用于:
所述缓存队列中存在连续RTP包时,从缓存队列中读取RTP包,然后从所述缓冲区读取RTP包。
4.根据权利要求2所述的机顶盒,其特征在于,所述处理器还用于:
所述缓存队列中存在丢包时,从所述缓冲区中读取一RTP包;
若所述RTP包为丢失的RTP包,则将所述RTP包传输至所述音视频解码芯片;
若所述RTP包不是丢失的RTP包,则将所述RTP包存储至所述缓存队列中。
5.根据权利要求1所述的机顶盒,其特征在于,所述处理器用于:
将RTP包从缓冲区读取至缓存队列中,判断是否达到第一丢包请求间隔,并且在达到所述第一丢包请求间隔且存在丢包时发出丢包重传请求;
在得到所述RTP包的传输码率后,在传输数据为第一码率时,判断是否达到第二丢包请求间隔,并且在达到所述第二丢包请求间隔且存在丢包时发出丢包重传请求;
在传输数据为第二码率时,判断是否达到第三丢包请求间隔,并且在达到所述第三丢包请求间隔且存在丢包时发出丢包重传请求;
所述第二码率大于所述第一码率时,所述第三丢包请求间隔小于所述第二丢包请求间隔。
6.根据权利要求1所述的机顶盒,其特征在于,所述处理器用于:
将所述RTP包以第一缓存速率从缓冲区读取至缓存队列中;
在得到所述RTP包的传输码率后,在传输数据为第一码率时,将所述RTP包以第二缓存速率从缓冲区读取至缓存队列中;
在传输数据为第二码率时,将所述RTP包以第三缓存速率从缓冲区读取至缓存队列中;
所述第二码率大于所述第一码率时,所述第三缓存速率大于所述第二缓存速率。
7.一种丢包处理方法,其特征在于,应用于机顶盒,包括:
从缓冲区读取RTP包,并解析所述RTP包的序号;
若所述RTP包的序号为0,则传输至音视频解码芯片;
从缓冲区读取另一RTP包,并存储至缓存队列中;
判断是否达到第一丢包请求间隔,并且在达到所述第一丢包请求间隔且存在丢包时发出丢包重传请求;
在得到所述RTP包的传输码率后,在传输数据为第一码率时,判断是否达到第二丢包请求间隔,并且在达到所述第二丢包请求间隔且存在丢包时发出丢包重传请求;
在传输数据为第二码率时,判断是否达到第三丢包请求间隔,并且在达到所述第三丢包请求间隔且存在丢包时发出丢包重传请求。
8.根据权利要求7所述的丢包处理方法,其特征在于,所述方法还包括:
从缓冲区读取RTP包,并解析所述RTP包的序号;
若所述RTP包的序号为0,则传输至音视频解码芯片;
将所述RTP包以第一缓存速率从缓冲区读取至缓存队列中;
在得到所述RTP包的传输码率后,在传输数据为第一码率时,将所述RTP包以第二缓存速率从缓冲区读取至缓存队列中;
在传输数据为第二码率时,将所述RTP包以第三缓存速率从缓冲区读取至缓存队列中。
9.根据权利要求7所述的丢包处理方法,其特征在于,所述方法还包括:
所述缓存队列中存在连续RTP包时,从缓存队列中读取RTP包,然后从所述缓冲区读取RTP包;
所述缓存队列中存在丢包时,从所述缓冲区中读取一RTP包;
若所述RTP包为丢失的RTP包,则将所述RTP包传输至所述音视频解码芯片;
若所述RTP包不是丢失的RTP包,则将所述RTP包存储至所述缓存队列中。
10.根据权利要求8所述的丢包处理方法,其特征在于,所述第二码率大于所述第一码率时,所述第三丢包请求间隔小于所述第二丢包请求间隔,所述第三缓存速率大于所述第二缓存速率。
CN202111554979.3A 2021-12-17 2021-12-17 一种机顶盒及丢包处理方法 Pending CN114257836A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111554979.3A CN114257836A (zh) 2021-12-17 2021-12-17 一种机顶盒及丢包处理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111554979.3A CN114257836A (zh) 2021-12-17 2021-12-17 一种机顶盒及丢包处理方法

Publications (1)

Publication Number Publication Date
CN114257836A true CN114257836A (zh) 2022-03-29

Family

ID=80792798

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111554979.3A Pending CN114257836A (zh) 2021-12-17 2021-12-17 一种机顶盒及丢包处理方法

Country Status (1)

Country Link
CN (1) CN114257836A (zh)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050005092A (ko) * 2003-07-01 2005-01-13 엘지전자 주식회사 미디어 재전송 장치 및 방법
CN101989902A (zh) * 2010-11-16 2011-03-23 中兴通讯股份有限公司 一种数据重传方法及装置
CN103533450A (zh) * 2013-06-09 2014-01-22 浙江宇视科技有限公司 一种媒体流可靠传输和接收的方法以及装置
CN103763073A (zh) * 2014-01-09 2014-04-30 深圳市迪威视讯股份有限公司 一种丢包重传的方法及终端
CN104244109A (zh) * 2014-09-19 2014-12-24 浙江宇视科技有限公司 一种媒体流可靠传输和接收的方法和装置
CN106850595A (zh) * 2017-01-17 2017-06-13 烽火通信科技股份有限公司 一种流媒体传输优化方法及装置
CN107147481A (zh) * 2017-07-19 2017-09-08 北京数码视讯科技股份有限公司 丢包重传方法、装置及电子设备
CN112019939A (zh) * 2019-05-31 2020-12-01 青岛海信宽带多媒体技术有限公司 Rtp包处理方法、装置及播放终端
CN113037440A (zh) * 2021-05-25 2021-06-25 腾讯科技(深圳)有限公司 数据重传处理方法、装置、计算机设备和存储介质

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050005092A (ko) * 2003-07-01 2005-01-13 엘지전자 주식회사 미디어 재전송 장치 및 방법
CN101989902A (zh) * 2010-11-16 2011-03-23 中兴通讯股份有限公司 一种数据重传方法及装置
CN103533450A (zh) * 2013-06-09 2014-01-22 浙江宇视科技有限公司 一种媒体流可靠传输和接收的方法以及装置
CN103763073A (zh) * 2014-01-09 2014-04-30 深圳市迪威视讯股份有限公司 一种丢包重传的方法及终端
CN104244109A (zh) * 2014-09-19 2014-12-24 浙江宇视科技有限公司 一种媒体流可靠传输和接收的方法和装置
CN106850595A (zh) * 2017-01-17 2017-06-13 烽火通信科技股份有限公司 一种流媒体传输优化方法及装置
CN107147481A (zh) * 2017-07-19 2017-09-08 北京数码视讯科技股份有限公司 丢包重传方法、装置及电子设备
CN112019939A (zh) * 2019-05-31 2020-12-01 青岛海信宽带多媒体技术有限公司 Rtp包处理方法、装置及播放终端
CN113037440A (zh) * 2021-05-25 2021-06-25 腾讯科技(深圳)有限公司 数据重传处理方法、装置、计算机设备和存储介质

Similar Documents

Publication Publication Date Title
US11483360B2 (en) Adaptive streaming with early client indication
CN110536179B (zh) 一种内容分发系统和方法
US7788395B2 (en) Adaptive media playback
US7594025B2 (en) Startup methods and apparatuses for use in streaming content
US6292834B1 (en) Dynamic bandwidth selection for efficient transmission of multimedia streams in a computer network
CN110290402A (zh) 一种视频码率调整方法、装置、服务器及存储介质
US20140095593A1 (en) Method and apparatus for transmitting data file to client
CN107071529A (zh) 一种hls视频播放方法、终端及服务器
US20090125634A1 (en) Network media streaming with partial syncing
US11678009B2 (en) Client, server, reception method and transmission method complied to moving picture experts group-dynamic adaptive streaming over HTTP standard
RU2598805C2 (ru) Способ для динамической адаптации частоты следования битов при приеме и соответствующий приемник
US20090296828A1 (en) Using program clock references to assist in transport of video stream to wireless device
Khan et al. QoE in DASH
CN110113662A (zh) 一种适应多种网络状况的视频监控客户端系统
CN111263240A (zh) Iptv 4k音视频播放管理方法、装置、显示设备
CN102439935B (zh) 媒体适配的方法和装置
Baik et al. VSync: Cloud based video streaming service for mobile devices
KR102304476B1 (ko) 적응적 스트리밍 서비스를 위한 다중 경로 기반 블록 전송 시스템 및 스트리밍 방법
CN111866526B (zh) 一种直播业务处理方法和装置
CN114257836A (zh) 一种机顶盒及丢包处理方法
CN110881018B (zh) 媒体流的实时接收方法及客户端
KR20190048186A (ko) 적응적 스트리밍 서비스를 위한 다중 경로 기반 분할 전송 시스템 및 스트리밍 방법
CN113207011A (zh) 一种短视频处理用预加载方法
KR100550099B1 (ko) 브이오디 서비스 시스템 및 그 서비스 방법
KR20220068636A (ko) 초저지연 ott 서비스를 제공하는 시스템 및 동작 방법

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