CN113132807B - 基于视频的关键帧请求方法、装置、设备及存储介质 - Google Patents

基于视频的关键帧请求方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN113132807B
CN113132807B CN201911393824.9A CN201911393824A CN113132807B CN 113132807 B CN113132807 B CN 113132807B CN 201911393824 A CN201911393824 A CN 201911393824A CN 113132807 B CN113132807 B CN 113132807B
Authority
CN
China
Prior art keywords
key frame
video
request
preset
frame request
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.)
Active
Application number
CN201911393824.9A
Other languages
English (en)
Other versions
CN113132807A (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.)
Chengdu TD Tech Ltd
Original Assignee
Chengdu TD Tech 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 Chengdu TD Tech Ltd filed Critical Chengdu TD Tech Ltd
Priority to CN201911393824.9A priority Critical patent/CN113132807B/zh
Publication of CN113132807A publication Critical patent/CN113132807A/zh
Application granted granted Critical
Publication of CN113132807B publication Critical patent/CN113132807B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/426Internal components of the client ; Characteristics thereof
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/437Interfacing the upstream path of the transmission network, e.g. for transmitting client requests to a VOD server
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00Reducing energy consumption in communication networks
    • Y02D30/70Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本申请提供一种基于视频的关键帧请求方法、装置、设备及存储介质,其中,该方法,包括:重复执行每间隔预设的第一时间,向录制设备发送关键帧请求,直至接收到完整的关键帧或者重复执行N次;该关键帧请求用于请求关键帧,N为大于等于1的正整数;然后接收录制设备发送的关键帧。从而可以解决现有技术中播放设备只能等待录制设备发出关键帧,进而容易出现视频不能正常播放的问题,保证视频播放的连贯性,提高视频的播放效果。

Description

基于视频的关键帧请求方法、装置、设备及存储介质
技术领域
本申请实施例涉及视频技术领域,尤其涉及一种基于视频的关键帧请求方法、装置、设备及存储介质。
背景技术
随着视频技术的发展,视频传输技术已经应用到各个领域中,在视频传输领域中,作为录制端的录制设备需要向作为播放端的播放设备发送关键帧;进而,播放设备可以根据关键帧开始视频的播放。
然而现有技术中,一旦播放设备没有及时的接收到关键帧,就会导致视频不能正常播放,甚至出现视频黑屏状态或者视频花屏状态。但是播放设备只能等待录制设备发出关键帧之后才能进行视频的播放,进而容易出现视频不能正常播放的情况。
发明内容
本申请实施例提供一种基于视频的关键帧请求方法、装置、设备及存储介质,用于解决现有技术中播放设备只能被动等待录制设备发出关键帧,进而容易出现视频不能正常播放的问题。
本申请第一方面提供一种基于视频的关键帧请求方法,所述方法,包括:
重复执行以下步骤,直至接收到完整的关键帧或者重复执行N次以下步骤:每间隔预设的第一时间,向录制设备发送关键帧请求,其中,所述关键帧请求用于请求关键帧,N为大于等于1的正整数;
接收所述录制设备发送的关键帧。
在一种可能的设计中,在所述向录制设备发送关键帧请求之前,还包括:
获取视频播放状态,并判断所述视频播放状态是否符合预设的关键帧触发条件;
若符合,则执行所述向录制设备发送关键帧请求的步骤。
在一种可能的设计中,所述关键帧触发条件为以下的任意一种或多种:
视频业务初始建立阶段;在预设的第二时间之内未接收到关键帧;接收到错误的关键帧;解码器初始化阶段;在预设的第三时间内的视频丢包率大于预设值,所述第三时间小于等于所述第一时间。
在一种可能的设计中,所述向录制设备发送关键帧请求,包括:
采用完整帧内请求消息,向所述录制设备发送所述关键帧请求;
或者
采用图像丢失指示消息,向所述录制设备发送所述关键帧请求。
在一种可能的设计中,在接收所述录制设备发送的关键帧之后,还包括:
根据所述关键帧,确定各个视频帧,以播放所述各个视频帧。
本申请第二方面提供一种基于视频的关键帧请求装置,所述装置,包括:
处理模块,用于重复执行以下步骤,直至接收到完整的关键帧或者重复执行N次以下步骤:每间隔预设的第一时间,向录制设备发送关键帧请求,其中,所述关键帧请求用于请求关键帧,N为大于等于1的正整数;
接收模块,用于接收所述录制设备发送的关键帧。
在一种可能的设计中,还包括:
获取模块,用于获取视频播放状态,并判断所述视频播放状态是否符合预设的关键帧触发条件;
若符合,则执行所述向录制设备发送关键帧请求的步骤。
在一种可能的设计中,所述关键帧触发条件为以下的任意一种或多种:
视频业务初始建立阶段;在预设的第二时间之内未接收到关键帧;接收到错误的关键帧;解码器初始化阶段;在预设的第三时间内的视频丢包率大于预设值,所述第三时间小于等于所述第一时间。
在一种可能的设计中,所述处理模块,具体用于:
采用完整帧内请求消息,向所述录制设备发送所述关键帧请求;
或者
采用图像丢失指示消息,向所述录制设备发送所述关键帧请求。
在一种可能的设计中,还包括:
播放模块,用于根据所述关键帧,确定各个视频帧,以播放所述各个视频帧。
本申请第三方面提供一种终端设备,包括:发送器、接收器、存储器和处理器;
所述存储器用于存储计算机指令;所述处理器用于运行所述存储器存储的所述计算机指令实现第一方面任一实现方式所述的方法。
本申请第四方面提供一种存储介质,包括:可读存储介质和计算机指令,所述计算机指令存储在所述可读存储介质中;所述计算机指令用于实现第一方面任一实现方式所述的方法。
本申请实施例提供的基于视频的关键帧请求方法、装置、设备及存储介质,通过重复执行每间隔预设的第一时间,向录制设备发送关键帧请求,直至接收到完整的关键帧或者重复执行N次;该关键帧请求用于请求关键帧,N为大于等于1的正整数;然后接收录制设备发送的关键帧。从而可以解决现有技术中播放设备只能等待录制设备发出关键帧,进而容易出现视频不能正常播放的问题,保证视频播放的连贯性,提高视频的播放效果。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其它的附图。
图1为本申请提供的应用场景示意图;
图2为本申请实施例提供的一种基于视频的关键帧请求方法的流程图;
图3为本申请实施例提供的另一种基于视频的关键帧请求方法的流程图;
图4为本申请实施例提供的一种基于视频的关键帧请求装置的结构示意图;
图5为本申请实施例提供的另一种基于视频的关键帧请求装置的结构示意图;
图6为本申请实施例提供的一种终端设备的结构示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例,都属于本申请保护的范围。
随着视频技术的发展,视频传输技术已经应用到各个领域中,在视频传输领域中,作为录制端的录制设备需要向作为播放端的播放设备发送I帧,I帧为关键帧;进而,播放设备可以根据I帧完成视频的播放。然而现有技术中,一旦播放设备没有及时的接收到关键帧,就会导致视频不能正常播放,甚至出现视频黑屏状态或者视频花屏状态。但是播放设备只能等待录制设备发出关键帧之后才能进行视频的播放,进而容易出现视频不能正常播放的情况。
针对上述技术问题,本申请提供一种基于视频的关键帧请求方法、装置、设备及存储介质,用于解决现有技术中播放设备只能等待录制设备发出关键帧,进而容易出现视频不能正常播放的问题。
图1为本申请提供的应用场景示意图,如图1所示,在视频传输领域中,作为录制端的录制设备需要向作为播放端的播放设备发送I帧作为关键帧使得播放设备可以根据I帧完成视频的播放。本申请中播放端可以根据视频播放状态,并判断判断视频播放状态是否符合预设的关键帧触发条件,从而向录制设备发起关键帧请求。其中,关键帧触发条件为以下的任意一种或多种:视频业务初始建立阶段;在预设的第二时间之内未接收到关键帧;接收到错误的关键帧;解码器初始化阶段;在预设的第三时间内的视频丢包率大于预设值,第三时间小于等于第一时间。具体地,播放端发起I帧请求的场景主要包括以下几种,现予以一一说明。在一种可能的应用场景中,视频业务初始建立时,立即触发I帧请求,可以保证播放端能够及时收到I帧,保证业务正常。在另一种可能的应用场景中,播放器在业务初始解码出现问题时触发I帧请求。这种情况包括两种具体的应用场景,一种为在预设的第二时间之内未接收到关键帧。即视频业务建立时,播放端在业务初始设定一个定时器T1,在定时器超时仍未收到I帧,则触发I帧请求。其中,T1为参数配置。另一种为接收到错误的关键帧。即视频业务建立时,播放端收到的I帧无法正确组帧,则触发I帧请求。在又一种可能的应用场景中,可以解码器初始化阶段触发I帧请求。具体地,视频业务过程中解码器初始化,例如从后台切换到前台,则触发I帧请求。在还一种可能的应用场景中,播放器在预设的第三时间内的视频丢包率大于预设值,则触发I帧请求。其中,第三时间小于等于第一时间。这种应用场景主要应用于丢包场景,播放端按照周期T2统计丢包率,如果出现丢包率大于门限值ParketLossRateTh时,则触发I帧请求。其中,参数丢包率判决周期T2的丢包门限ParketLossRateTh可参数配置。这种机制可以有效解决瞬时丢包导致的视频连续花屏问题。对弱覆盖连续丢包导致的视频花屏现象效果不大,但是能够保证终端弱覆盖地区移动到网络条件良好的区域能够及时恢复视频画面。
为了保证播放端I帧请求报文能够有效传递到录制端,又能够不频繁发送I帧请求报文,播放端可以重复执行关键帧请求,直至接收到完整的关键帧或者重复执行N次关键帧请求。其中,需要对播放端的I帧请求周期次数和周期进行限制。在发送I帧请求之后,如果在预设的周期T3内没有收到完整I帧,则重发I帧请求,或者重复执行N次。即使播放端在周期内收到I帧,当时只要I帧不完整,仍需要在下个周期重新申请。重发周期T3和重发次数N次参数可配置,例如N可以配置无穷大。在一个周期内不会进行发送两次I帧请求。即为在一个周期内及时出现两个触发I帧请求的事件,例如后台切换前台收到的视频流丢包,也不会发送两次I帧请求。
同时,还可以对播放端I帧请求的机制做设计,本实施例对I帧请求承载的报文不做限制,可以通过PLI(Full Intra Request,完整帧内请求消息)和FIR(Picture LossIndication,图像丢失指示)或者其他方式传递到录制端,播放端均可进行适配。
应用上述方法可以解决现有技术中播放设备只能等待录制设备发出关键帧,进而容易出现视频不能正常播放的问题,保证视频播放的连贯性,提高视频的播放效果。
图2为本申请实施例提供的一种基于视频的关键帧请求方法的流程图,如图2所示,该方法,包括:重复执行以下步骤,直至接收到完整的关键帧或者重复执行N次以下步骤:
S101、每间隔预设的第一时间,向录制设备发送关键帧请求。
本实施例中,可以采用完整帧内请求消息,向录制设备发送关键帧请求;或者采用图像丢失指示消息,向录制设备发送关键帧请求。其中,关键帧请求用于请求关键帧,N为大于等于1的正整数。
具体地,对于实时视频业务,录制端发送I帧的时间间隔取决于录制器的配置,协议是没有限制的。对于没有周期性发送I帧或者I帧间隔周期较长的的视频业务,如果终端解码器初始化之后没有及时收到完整的I帧或者视频业务中数据流存在突发的丢包场景,视频画面会持续处于黑屏或者花屏状态,直到收到新的I帧刷新画面,严重影响业务感知。
为了保证播放端I帧请求报文能够有效传递到录制端,又能够不频繁发送I帧请求报文。需要对播放端的I帧请求周期次数和周期进行限制。在发送I帧请求之后,如果在预设的周期T3内没有收到完整I帧,则重发I帧请求,或者重复执行N次。即使播放端在周期内收到I帧,当时只要I帧不完整,仍需要在下个周期重新申请。重发周期T3和重发次数N次参数可配置,例如N可以配置无穷大。在一个周期内不会进行发送两次I帧请求。即为在一个周期内及时出现两个触发I帧请求的事件,例如后台切换前台收到的视频流丢包,也不会发送两次I帧请求。还可以对播放端I帧请求的机制做设计,本实施例对I帧请求承载的报文不做限制,可以通过PLI(Full Intra Request,完整帧内请求消息)和FIR(Picture LossIndication,图像丢失指示)或者其他方式传递到录制端,播放端均可进行适配。
S102、接收录制设备发送的关键帧。
本实施例中,播放端接收录制设备发送的关键帧。在接收录制设备发送的关键帧之后,还可以包括:根据关键帧,确定各个视频帧,以播放各个视频帧。
具体地,播放端根据接收到的关键帧,可以确定各个视频帧,从而播放各个视频帧,解决视频不能正常播放,甚至出现视频黑屏状态或者视频花屏的技术问题。对关键帧的接收和根据关键帧播放各个视频帧为现有技术,此处不再赘述。
本实施例,通过重复执行每间隔预设的第一时间,向录制设备发送关键帧请求,直至接收到完整的关键帧或者重复执行N次;该关键帧请求用于请求关键帧,N为大于等于1的正整数;然后接收录制设备发送的关键帧。从而可以解决现有技术中播放设备只能等待录制设备发出关键帧,进而容易出现视频不能正常播放的问题,保证视频播放的连贯性,提高视频的播放效果。
图3为本申请实施例提供的另一种基于视频的关键帧请求方法的流程图,如图3所示,该方法,包括:
S201、获取视频播放状态,并判断视频播放状态是否符合预设的关键帧触发条件。
本实施例中,播放端首先获取视频播放状态,并判断判断视频播放状态是否符合预设的关键帧触发条件。其中,关键帧触发条件为以下的任意一种或多种:视频业务初始建立阶段;在预设的第二时间之内未接收到关键帧;接收到错误的关键帧;解码器初始化阶段;在预设的第三时间内的视频丢包率大于预设值,第三时间小于等于第一时间。
具体地,当前RFC协议已经支持I帧请求,播放端根据需求通过发送RTCP-FIR(RFC5104协议)或者RTCP-PLI(RFC4585协议)报告到录制端申请完整的I帧。但是对于播放端在什么状态下需要I帧请求没有做限制。本实施例中播放端发起I帧请求的场景主要包括以下几种,现予以一一说明。在一种可能的应用场景中,视频业务初始建立时,立即触发I帧请求,可以保证播放端能够及时收到I帧,保证业务正常。
在另一种可能的应用场景中,播放器在业务初始解码出现问题时触发I帧请求。这种情况包括两种具体的应用场景,一种为在预设的第二时间之内未接收到关键帧。即视频业务建立时,播放端在业务初始设定一个定时器T1,在定时器超时仍未收到I帧,则触发I帧请求。其中,T1为参数配置。另一种为接收到错误的关键帧。即视频业务建立时,播放端收到的I帧无法正确组帧,则触发I帧请求。
在又一种可能的应用场景中,可以解码器初始化阶段触发I帧请求。具体地,视频业务过程中解码器初始化,例如从后台切换到前台,则触发I帧请求。
在还一种可能的应用场景中,播放器在预设的第三时间内的视频丢包率大于预设值,则触发I帧请求。其中,第三时间小于等于第一时间。这种应用场景主要应用于丢包场景,播放端按照周期T2统计丢包率,如果出现丢包率大于门限值ParketLossRateTh时,则触发I帧请求。其中,参数丢包率判决周期T2的丢包门限ParketLossRateTh可参数配置。这种机制可以有效解决瞬时丢包导致的视频连续花屏问题。对弱覆盖连续丢包导致的视频花屏现象效果不大,但是能够保证终端弱覆盖地区移动到网络条件良好的区域能够及时恢复视频画面。
S202、若符合,则执行向录制设备发送关键帧请求的步骤。
本实施例中,若视频播放状态符合预设的关键帧触发条件,则重复执行步骤S203、S204,直至接收到完整的关键帧或者重复执行N次以下步骤。
S203、间隔预设的第一时间,向录制设备发送关键帧请求。
S204、接收录制设备发送的关键帧。
本实施例中,步骤S203~步骤S204的具体实现过程和技术原理请参见图2所示的方法中步骤S101~步骤S102中的相关描述,此处不再赘述。
本实施例,通过重复执行每间隔预设的第一时间,向录制设备发送关键帧请求,直至接收到完整的关键帧或者重复执行N次;该关键帧请求用于请求关键帧,N为大于等于1的正整数;然后接收录制设备发送的关键帧。从而可以解决现有技术中播放设备只能等待录制设备发出关键帧,进而容易出现视频不能正常播放的问题,保证视频播放的连贯性,提高视频的播放效果。
另外,本实施例还可以获取视频播放状态,并判断判断视频播放状态是否符合预设的关键帧触发条件。其中,关键帧触发条件为以下的任意一种或多种:视频业务初始建立阶段;在预设的第二时间之内未接收到关键帧;接收到错误的关键帧;解码器初始化阶段;在预设的第三时间内的视频丢包率大于预设值,第三时间小于等于第一时间。从而可以解决现有技术中播放设备只能等待录制设备发出关键帧,进而容易出现视频不能正常播放的问题,保证视频播放的连贯性,提高视频的播放效果。
图4为本申请实施例提供的一种基于视频的关键帧请求装置的结构示意图,如图4所示,本实施例的基于视频的关键帧请求装置,包括:
处理模块31,用于重复执行以下步骤,直至接收到完整的关键帧或者重复执行N次以下步骤:每间隔预设的第一时间,向录制设备发送关键帧请求,其中,关键帧请求用于请求关键帧,N为大于等于1的正整数;
接收模块32,用于接收录制设备发送的关键帧。
在一种可能的设计中,处理模块32,具体用于:
采用完整帧内请求消息,向录制设备发送关键帧请求;
或者
采用图像丢失指示消息,向录制设备发送关键帧请求。
本实施例的基于视频的关键帧请求装置,可以执行图2所示方法中的技术方案,其具体实现过程和技术原理参见图2所示方法中的相关描述,此处不再赘述。
本实施例,通过重复执行每间隔预设的第一时间,向录制设备发送关键帧请求,直至接收到完整的关键帧或者重复执行N次;该关键帧请求用于请求关键帧,N为大于等于1的正整数;然后接收录制设备发送的关键帧。从而可以解决现有技术中播放设备只能等待录制设备发出关键帧,进而容易出现视频不能正常播放的问题,保证视频播放的连贯性,提高视频的播放效果。
图5为本申请实施例提供的另一种基于视频的关键帧请求装置的结构示意图,如图5所示,本实施例的基于视频的关键帧请求装置在图4所示装置的基础上,还可以包括:
获取模块33,用于获取视频播放状态,并判断视频播放状态是否符合预设的关键帧触发条件;
若符合,则执行向录制设备发送关键帧请求的步骤。
在一种可能的设计中,关键帧触发条件为以下的任意一种或多种:
视频业务初始建立阶段;在预设的第二时间之内未接收到关键帧;接收到错误的关键帧;解码器初始化阶段;在预设的第三时间内的视频丢包率大于预设值,第三时间小于等于第一时间。
在一种可能的设计中,还包括:
播放模块34,用于根据关键帧,确定各个视频帧,以播放各个视频帧。
本实施例的基于视频的关键帧请求装置,可以执行图2、图3所示方法中的技术方案,其具体实现过程和技术原理参见图2、图3所示方法中的相关描述,此处不再赘述。
本实施例,通过重复执行每间隔预设的第一时间,向录制设备发送关键帧请求,直至接收到完整的关键帧或者重复执行N次;该关键帧请求用于请求关键帧,N为大于等于1的正整数;然后接收录制设备发送的关键帧。从而可以解决现有技术中播放设备只能等待录制设备发出关键帧,进而容易出现视频不能正常播放的问题,保证视频播放的连贯性,提高视频的播放效果。
另外,本实施例还可以获取视频播放状态,并判断判断视频播放状态是否符合预设的关键帧触发条件。其中,关键帧触发条件为以下的任意一种或多种:视频业务初始建立阶段;在预设的第二时间之内未接收到关键帧;接收到错误的关键帧;解码器初始化阶段;在预设的第三时间内的视频丢包率大于预设值,第三时间小于等于第一时间。从而可以解决现有技术中播放设备只能等待录制设备发出关键帧,进而容易出现视频不能正常播放的问题,保证视频播放的连贯性,提高视频的播放效果。
图6为本申请实施例提供的一种终端设备的结构示意图,如图6所示,该终端设备,包括:发送器41、接收器42、存储器43和处理器44。
存储器43用于存储计算机指令;处理器44用于运行存储器43存储的计算机指令实现前述实施例提供任一实现方式的基于视频的关键帧请求方法的技术方案。
本实施例的终端设备,可以执行图2、图3所示方法中的技术方案,其具体实现过程和技术原理参见图2、图3所示方法中的相关描述,此处不再赘述。
本实施例,通过重复执行每间隔预设的第一时间,向录制设备发送关键帧请求,直至接收到完整的关键帧或者重复执行N次;该关键帧请求用于请求关键帧,N为大于等于1的正整数;然后接收录制设备发送的关键帧。从而可以解决现有技术中播放设备只能等待录制设备发出关键帧,进而容易出现视频不能正常播放的问题,保证视频播放的连贯性,提高视频的播放效果。
本申请还提供一种存储介质,包括:可读存储介质和计算机指令,计算机指令存储在可读存储介质中;计算机指令用于实现前述例提供的任一实现方式的基于视频的关键帧请求方法的技术方案。
在上述终端设备的具体实现中,应理解,处理器可以是中央处理单元(英文:Central Processing Unit,简称:CPU),还可以是其他通用处理器、数字信号处理器(英文:Digital Signal Processor,简称:DSP)、专用集成电路(英文:Application SpecificIntegrated Circuit,简称:ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。
本领域普通技术人员可以理解:实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时,执行包括上述各方法实施例的步骤;而前述的存储介质包括:只读存储器(英文:read-only memory,缩写:ROM)、RAM、快闪存储器、硬盘、固态硬盘、磁带(英文:magnetictape)、软盘(英文:floppy disk)、光盘(英文:optical disc)及其任意组合。
最后应说明的是:以上各实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述各实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (8)

1.一种基于视频的关键帧请求方法,其特征在于,所述方法,包括:
获取视频播放状态,并判断所述视频播放状态是否符合预设的关键帧触发条件;所述关键帧触发条件为以下的任意一种或多种:视频业务初始建立阶段;至视频初始建立时刻起,在预设的第二时间之内未接收到关键帧;视频业务建立时接收到错误的关键帧;解码器初始化阶段;在预设的第三时间内的视频丢包率大于预设值,所述第三时间小于等于第一时间;
若符合,则
重复执行每间隔预设的第一时间,向录制设备发送关键帧请求,直至接收到完整的关键帧或者重复执行N次其中,所述关键帧请求用于请求所述关键帧,N为大于等于1的正整数;
接收所述录制设备发送的所述关键帧。
2.根据权利要求1所述的方法,其特征在于,所述向录制设备发送关键帧请求,包括:
采用完整帧内请求消息,向所述录制设备发送所述关键帧请求;
或者
采用图像丢失指示消息,向所述录制设备发送所述关键帧请求。
3.根据权利要求1所述的方法,其特征在于,在接收所述录制设备发送的关键帧之后,还包括:
根据所述关键帧,确定各个视频帧,以播放所述各个视频帧。
4.一种基于视频的关键帧请求装置,其特征在于,所述装置,包括:
获取模块,用于获取视频播放状态,并判断所述视频播放状态是否符合预设的关键帧触发条件;
若符合,则执行向录制设备发送关键帧请求的步骤;所述关键帧触发条件为以下的任意一种或多种:
视频业务初始建立阶段;至视频初始建立时刻起,在预设的第二时间之内未接收到关键帧;视频业务建立时接收到错误的关键帧;解码器初始化阶段;在预设的第三时间内的视频丢包率大于预设值,所述第三时间小于等于第一时间;
处理模块,用于重复执行以下步骤,直至接收到完整的关键帧或者重复执行N次以下步骤:每间隔预设的第一时间,向录制设备发送关键帧请求,其中,所述关键帧请求用于请求关键帧,N为大于等于1的正整数;
接收模块,用于接收所述录制设备发送的关键帧。
5.根据权利要求4所述的装置,其特征在于,所述处理模块,具体用于:
采用完整帧内请求消息,向所述录制设备发送所述关键帧请求;
或者
采用图像丢失指示消息,向所述录制设备发送所述关键帧请求。
6.根据权利要求4所述的装置,其特征在于,还包括:
播放模块,用于根据所述关键帧,确定各个视频帧,以播放所述各个视频帧。
7.一种终端设备,其特征在于,包括:发送器、接收器、存储器和处理器;
所述存储器用于存储计算机指令;所述处理器用于运行所述存储器存储的所述计算机指令实现权利要求1-3任一项所述的方法。
8.一种存储介质,其特征在于,包括:可读存储介质和计算机指令,所述计算机指令存储在所述可读存储介质中;所述计算机指令用于实现权利要求1-3任一项所述的方法。
CN201911393824.9A 2019-12-30 2019-12-30 基于视频的关键帧请求方法、装置、设备及存储介质 Active CN113132807B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911393824.9A CN113132807B (zh) 2019-12-30 2019-12-30 基于视频的关键帧请求方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911393824.9A CN113132807B (zh) 2019-12-30 2019-12-30 基于视频的关键帧请求方法、装置、设备及存储介质

Publications (2)

Publication Number Publication Date
CN113132807A CN113132807A (zh) 2021-07-16
CN113132807B true CN113132807B (zh) 2023-04-07

Family

ID=76767922

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911393824.9A Active CN113132807B (zh) 2019-12-30 2019-12-30 基于视频的关键帧请求方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN113132807B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113965714B (zh) * 2021-09-10 2023-06-23 北京百度网讯科技有限公司 视频流的处理方法、装置、电子设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1152243A (zh) * 1995-08-02 1997-06-18 索尼公司 用于对数字视频数据进行编码和解码的设备和方法
CN102347943A (zh) * 2010-07-29 2012-02-08 三星电子株式会社 基于rtsp会话发送和接收流传输数据的方法和设备

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8634413B2 (en) * 2004-12-30 2014-01-21 Microsoft Corporation Use of frame caching to improve packet loss recovery
CN101998101A (zh) * 2009-08-31 2011-03-30 中兴通讯股份有限公司 可视电话的视频数据接收和发送系统、视频数据处理方法
CN101697554B (zh) * 2009-09-27 2012-05-09 华中科技大学 一种p2p流媒体视频数据传输调度方法
US8731152B2 (en) * 2010-06-18 2014-05-20 Microsoft Corporation Reducing use of periodic key frames in video conferencing
CN101990087A (zh) * 2010-09-28 2011-03-23 深圳中兴力维技术有限公司 无线视频监控系统及根据网络状态动态调整码流的方法
CN102547411A (zh) * 2010-12-14 2012-07-04 康佳集团股份有限公司 流视频的传输和播放方法及其实现装置
US8666042B2 (en) * 2011-11-02 2014-03-04 Cisco Technology, Inc. Techniques for performing key frame requests in media servers and endpoint devices
CN103533387B (zh) * 2013-10-21 2016-08-17 腾讯科技(深圳)有限公司 一种视频直播控制方法、设备及系统
CN110392269B (zh) * 2018-04-17 2021-11-30 腾讯科技(深圳)有限公司 媒体数据处理方法和装置、媒体数据播放方法和装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1152243A (zh) * 1995-08-02 1997-06-18 索尼公司 用于对数字视频数据进行编码和解码的设备和方法
CN102347943A (zh) * 2010-07-29 2012-02-08 三星电子株式会社 基于rtsp会话发送和接收流传输数据的方法和设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"基于H.264和DASH视频传输系统的设计".《中国优秀硕士学位论文全文数据库》.2018,全文. *

Also Published As

Publication number Publication date
CN113132807A (zh) 2021-07-16

Similar Documents

Publication Publication Date Title
WO2020192152A1 (zh) 视频传输的方法、根节点、子节点、p2p服务器和系统
CN106686438B (zh) 一种跨设备的音频图像同步播放的方法、装置及系统
CN110784740A (zh) 视频处理方法、装置、服务器及可读存储介质
US10171815B2 (en) Coding manner switching method, transmit end, and receive end
CA2758763C (en) Method and device for fast pushing unicast stream in fast channel change
CN108347580B (zh) 一种处理视频帧数据的方法及电子设备
CN113992967B (zh) 一种投屏数据传输方法、装置、电子设备及存储介质
CN109040830B (zh) 直播播放卡顿的预测方法、切换方法及装置
WO2019101089A1 (zh) 视频发送、接收方法和装置及终端
CN108471548B (zh) 直播视频快速播放方法及装置
CN109714622A (zh) 一种视频数据处理方法、装置及电子设备
CN110062268A (zh) 一种音视频同屏播放的发送和接收处理方法及装置
US10142644B2 (en) Decoding frames
WO2021238940A1 (zh) 视频数据处理方法、装置和电子设备
CN115643449B (zh) 云服务的视频显示方法、装置、设备、存储介质和系统
CN113132807B (zh) 基于视频的关键帧请求方法、装置、设备及存储介质
CN108966006A (zh) 视频的播放方法、浏览器设备及可读存储介质
CN106331820B (zh) 音视频的同步处理方法和装置
CN103929682B (zh) 一种在视频直播系统中设置关键帧的方法及装置
CN109862400B (zh) 一种流媒体传输方法、装置及其系统
CN108540273B (zh) 一种数据包重传的方法和装置
CN109831693B (zh) 一种视频帧信息数据上报及判定数据下溢的方法
CN107566318B (zh) 流媒体数据的修复方法及装置
CN112153413B (zh) 一种同屏广播处理花屏的方法和服务器
KR20130141368A (ko) 수신장치 및 수신장치용 프로그램

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
GR01 Patent grant
GR01 Patent grant