CN1976306A - 媒体请求响应时间的测试方法和测试装置 - Google Patents

媒体请求响应时间的测试方法和测试装置 Download PDF

Info

Publication number
CN1976306A
CN1976306A CNA2006101386279A CN200610138627A CN1976306A CN 1976306 A CN1976306 A CN 1976306A CN A2006101386279 A CNA2006101386279 A CN A2006101386279A CN 200610138627 A CN200610138627 A CN 200610138627A CN 1976306 A CN1976306 A CN 1976306A
Authority
CN
China
Prior art keywords
time
packet
condition code
media
data
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
CNA2006101386279A
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CNA2006101386279A priority Critical patent/CN1976306A/zh
Publication of CN1976306A publication Critical patent/CN1976306A/zh
Pending legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了媒体请求响应时间的测试方法和测试装置,其核心思想为捕获分析数据包,获取发出媒体请求信息的时间和媒体数据特征码到达的时间,依据这两个时间计算媒体请求响应时间。本发明能够实现准确测试媒体请求响应时间。

Description

媒体请求响应时间的测试方法和测试装置
技术领域
本发明涉及媒体数据测试技术,尤其涉及媒体请求响应时间的测试方法和测试装置。
背景技术
用户侧体验的效果是评价娱乐类产品的最重要指标之一,而媒体服务响应时间是用户侧体验的一个重要参数。在BTV(直播)、VoD(点播)、PLTV(时移电视)等媒体服务的请求、控制等操作中,都需要测量媒体服务响应用户操作的速度。媒体服务响应时间包括媒体请求响应时间和STB(终端)对接收到的媒体数据处理时间,因为终端对媒体数据的解码时间为毫秒级,而媒体请求响应时间通常为秒级,故把媒体请求响应时间看成是评定媒体服务响应时间的指标。
在多媒体播放中,解码器在接收到媒体数据的I帧(Intra Picture,帧内图)之后,才能开始对一个GOP(Group of Pictures,图片组)进行解码。终端发出媒体内容请求后,收到的数据的第一帧并不一定是I帧,在请求直播节目中,由于是实时编码的媒体内容传送,用户请求被确认后接收的第一帧是根据实际的编码状态决定,即是由随机序列产生,而点播节目中,则是根据文件录制时候的编码配置参数所决定。
现有技术对媒体请求响应时间的测试方法如下:
请参考图1,为现有技术点播响应时间测试示意图。终端101发起点播请求。该点播请求得到点播服务器102确认后,点播服务器102反馈200.OK报文,终端101与点播服务器102建立了完整的连接,连接建立后下发媒体流。200.OK标志符为终端101向点播服务器102发起建立连接请求,该请求被服务器端成功响应后返回给请求者的确认消息,由RTSP1.0协议定义。通过抓包可以分析出点播媒体的第一个媒体数据包(即200.OK报文后的终端101收到的第一个RTP包)的到达时间。终端101收到的第一个RTP包是指在200.OK后的第一个数据包,可以根据源地址和目的地址来筛选第一个RTP包。
请参考图2,为现有技术直播响应时间测试示意图。终端201发起直播频道组加入请求。直播服务器202对消息进行鉴权后允许加入请求的媒体,返回允许加入请求,直播媒体流开始下发。通过抓包可以分析出直播媒体的第一个媒体数据包(即终端201发出直播频道组报文后收到的所请求的组播组的第一个UDP数据包)的到达时间。该组播组的第一个UDP数据包是指用户请求某个频道,根据该频道地址和端口匹配在捕获的报文中进行过滤筛选的数据包。
从以上的测试可以看出,不管是点播还是直播,现有技术以发出媒体请求至捕获第一个媒体数据包的到达时间作为服务器的媒体请求响应时间。但是,这个测试处理的时间并不能代表真实的媒体请求响应时间,根据媒体由帧组成的定义以及解码过程定义,终端需要在收到I帧的时候才能够将媒体数据解码为图像,在终端上显示出来,而在终端得到第一个数据包时,这个数据包并不一定携带的是I帧,即终端与媒体服务器连接建立完成后,终端收到的数据帧中第一帧并不一定是I帧,可能是B帧或者P帧,需要缓冲等待I帧,待I帧到达后才可以解码在终端上显示出图像。以发出请求至第一个数据包到达的时间作为媒体请求响应时间的测试方法是不够准确的。
发明内容
本发明要解决的技术问题是提供媒体请求响应时间的测试方法和测试装置,以实现准确测试媒体请求响应时间。
为解决上述技术问题,本发明通过以下技术方案实现:
一种媒体请求响应时间的测试方法,包括:获取发出媒体请求信息的时间;
获取媒体数据特征码到达的时间;依据所述发出媒体请求信息的时间和所述媒体数据特征码到达的时间,计算媒体请求响应时间。
可选的,所述媒体请求包括直播请求和/或点播请求。
可选的,所述获取媒体数据特征码到达的时间前,捕获媒体数据特征码。
可选的,所述的计算过程为,所述媒体数据特征码到达的时间减去所述发出媒体请求信息的时间。
可选的,所述特征码为帧内图。
一种媒体请求响应时间的测试装置,包括:抓包分析单元、发出请求时间获取单元、特征码到达时间获取单元和媒体请求响应时间计算单元;抓包分析单元,用于捕获并分析数据包,判断是否捕获到媒体请求报文和媒体数据特征码;发出请求时间获取单元,用于当所述抓包分析单元捕获到媒体请求报文时,获取发出媒体请求报文的时间;特征码到达时间获取单元,用于当所述抓包分析单元捕获到媒体数据特征码时,获取媒体数据特征码到达的时间;媒体请求响应时间计算单元,用于根据所述发出媒体请求报文的时间和所述媒体数据特征码到达的时间,计算媒体请求响应时间。
可选的,还包括数据接收端口;数据接收端口,用于接收用户接入设备发送的待分析数据包,向所述抓包分析单元发送所述数据包。
可选的,还包括多线程处理单元;多线程处理单元,用于处理所述数据接收端口向所述抓包分析单元发送的数据包,当从所述数据接收端口接收到多个不同目的地址的数据包时,依据多线程的处理方式,并行把所述数据包发送给所述抓包分析单元。
可选的,还包括至少一个数据上行端口、至少一个数据下行端口和镜像处理单元;数据上行端口,用于与媒体服务器进行数据传输;数据下行端口,用于与终端进行数据传输;镜像处理单元,用于复制所述数据上行端口和所述数据下行端口传输的数据包,向所述抓包分析单元发送所述数据包。
可选的,还包括多线程处理单元;多线程处理单元,用于处理所述镜像处理单元向所述抓包分析单元发送的数据包,当从所述镜像处理单元接收到多个不同目的地址的数据包时,根据多线程的处理方式,并行把所述数据包发送给所述抓包分析单元。
以上技术方案可以看出,本发明获取发出媒体请求信息的时间和媒体数据特征码到达的时间,依据所述发出媒体请求信息的时间和所述媒体数据特征码到达的时间,计算媒体请求响应时间;因为特征码到达后,终端开始进行解码工作,因此根据本发明测试出来的从发出媒体请求信息至媒体数据特征码到达的时间,是准确的媒体请求响应时间。
附图说明
图1为现有技术点播响应时间测试示意图;
图2为现有技术直播响应时间测试示意图;
图3为本发明实施例的方法流程图;
图4为图片组帧关系示意图;
图5为I帧的格式示意图;
图6为本发明第一实施例测试装置示意图;
图7为本发明第二实施例测试装置示意图。
具体实施方式
本发明提供媒体请求响应时间的测试方法和测试装置,其核心思想为捕获分析数据包,获取发出媒体请求信息的时间和媒体数据特征码到达的时间,依据这两个时间计算媒体请求响应时间。
请参考图3,为本发明实施例的方法流程图。
步骤301.终端发出媒体请求。媒体请求主要包括直播请求和点播请求。
直播业务是以组播的方式传递媒体流至终端,在IPV4中,采用IGMP协议(Internet Group Management Protocol,因特网组管理协议),在IPV6中,采用MLD协议(Multicast Listener Discovery,组播监听发现),直播频道的每一个频道就是一个组播组,终端加入某一频道,则需要申请加入该频道所在的组播组,首先需要发起IGMP REPORT报文,申请加入该组播组,上层设备将此请求发送给更高一层的设备,更高一层的设备根据IGMP REPORT报文中的信息来判断是否存在该组,如果存在,则反馈消息说明该组存在,STB发起IGMP JOIN组播组加入报文,上层设备收到此消息并经过鉴权后,允许终端加入该组播组,并将媒体流下发给STB,用户完成直播业务请求过程。
点播业务是以单播的形式传递给终端,采用RTSP协议(RTSP Real-TimeStreaming Protocol,实时流协议),终端(STB)发起点播请求,即RTSP请求,承载网作透传,并附带请求节目的相关信息,如时间段,节目名称,服务器收到终端的请求后,经过鉴权,返回给终端200.OK的信息,表明服务器端已经响应终端的请求,终端与点播服务器的通道建立后将媒体数据下发给终端,用户完成点播业务过程。
具体的,VOD(Video on Demand,视频点播)为RTSP消息,nVoD(NearVideo On Demand,准视频点播)为IGMP消息和MLD消息,PLTV为RTSP消息,IGMP消息和MLD消息,TVOD(TV Video On Demand,电视点播)为RTSP消息。
步骤302.获取发出媒体请求的时间。
不管是RTSP、IGMP还是MLD协议,协议规定报文携带的信息是特定的,这是由标准化组织的协议规范所定义,而相关的设备如终端设备,承载网设备路由器等均遵循这些协议规范,所以可以通过捕获数据包的方法,获取发出媒体请求的时间。在本实施例中,使用镜像抓包分析捕获的数据包,镜像抓包是指将一个端口的数据包完全复制到另一个端口上,并从复制了数据的端口进行捕获分析,使用镜像复制的过程不会影响正常的数据包传输。
步骤303.终端接收媒体数据。经过确认终端请求后,媒体服务器下发媒体流,媒体流的编码格式包括MPEG1,MPEG2,MPEG4,H.264和WMV等。
媒体数据有自己固定的数据结构,它是由各种视频帧组成。在MPEG规范中,都定义了I、P、B这三种帧,分别简称为帧内图(Intra Picture)、预测图(Predicted Picture)及双向图(Bidirectional Predicted Picture),即I帧、P帧及B帧,其中I帧是不依靠其他帧就可以解码的帧类型,B帧和P帧都需要以其他帧的数据作为参考才能完全解码的帧类型。在这些帧中,I帧的压缩率最差,而B帧和P帧分别使用了双向和单向运动补偿预测技术,压缩率都优于I帧。通常,媒体数据以GOP的形式组织,以满足随机存取的要求。GOP是一组由相邻的,编码好的帧组成的连续图像序列,在GOP中,第一帧的帧类型是I帧。请参考图4,为图片组帧关系示意图,其中:P Frame高编码;I Frame随机存取;B Frame高压缩。
每一种类型的视频帧,即I帧,B帧,P帧,都是有着各自的帧组成结构,每种帧的组成结构是不同的,可以根据不同特征代码分析帧的组成结构来判断帧的类型是I帧,B帧或者P帧。请参考图5,为I帧的格式示意图。在视频媒体传输的过程中,当终端获取到第一个I帧后,视频图像才会在终端设备上显示出来。
步骤304.获取媒体数据特征码到达的时间。在本实施例中,因为I帧到达后,才进行解码,故把I帧看成是媒体数据的特征码。
使用镜像抓包的方法,捕获终端接收的媒体流,镜像抓取的内容为从发起请求到接收到媒体数据这段过程中的所有数据包。对抓取的媒体流进行分析,主要行为是根据帧的特征代码分析终端按顺序接收的数据包中的帧是否是I帧。
进一步,还可以分析媒体数据传输方式。当前媒体流传输方式包括TS和ISMA。业界主要的标准化组织都选择TS流作为传输标准,包括美国的ATSC、欧洲的DVB、日本的ISDB等,中国的数字电视传输标准也采用TS,涵盖了SDTV到HDTV范围内的应用。TS传输标准由ISO制订,属于ISO/IEC13818的一部分。ISMA(互联网流媒体联盟)是在2003年形成的标准,目标之一是为了解决IP网上媒体传送的交互性上,因此定义了回传机制。ISMA是一个标准集合,其中传输标准选择了RTP/RTCP。MPEG1/2可以使用RFC2250进行封装、MPEG-4ASP封装在RFC3640或TS流中进行传输、H.264封装在RFC3984或TS流中进行传输。
获取特征码的方法举例,以下为其中一种具体实现方式:
rtp_header_t*rtp_header=(rtp_header_t*)buf;
_u32*payload_header=(_u32*)(buf+sizeof(rtp_header_t));
char*frame_type=buf+sizeof(rtp_header_t)+4;
if((*payload_header==htonl(0x000001b6))&&((*frame_type&0xC0)==0x00))
channel->table->keyframe=1;)
步骤305.计算出媒体响应时间。
通过匹配帧的特征代码得到媒体流第一个I帧的到达时间。I帧到达的时间与终端发起请求的时间长度即为得到的媒体请求响应时间。
时间长度的计算方法两个实例:第一种记录方法为终端发出请求的时间到收到第一个I帧的时间,这段时间即为媒体请求响应时间;第二种方法为分别记录终端发出请求的时间和第一个I帧的到达时间,两个时间之差即为媒体请求响应时间。
请参考图6,为本发明第一实施例测试装置示意图。一种媒体请求响应时间的测试装置610,包括:抓包分析单元613、发出请求时间获取单元614、特征码到达时间获取单元615、媒体请求响应时间计算单元616、数据接收端口611和多线程处理单元612。
数据接收端口611,用于接收用户接入设备发送的待分析数据包,向所述抓包分析单元613发送所述数据包。
多线程处理单元612,用于处理所述数据接收端口611向所述抓包分析单元613发送的数据包,当从所述数据接收端口611接收到多个不同目的地址的数据包时,依据多线程的处理方式,并行把所述数据包发送给所述抓包分析单元613。
抓包分析单元613,用于捕获并分析数据包,判断是否捕获到媒体请求报文和媒体数据特征码。
发出请求时间获取单元614,用于当所述抓包分析单元613捕获到媒体请求报文时,获取发出媒体请求报文的时间。
特征码到达时间获取单元615,用于当所述抓包分析单元613捕获到媒体数据特征码时,获取媒体数据特征码到达的时间。
媒体请求响应时间计算单元616,用于根据所述发出请求时间获取单元614获取发出媒体请求报文的时间和所述特征码到达时间获取单元615获取媒体数据特征码到达的时间,计算媒体请求响应时间。
以下为本实施例测试装置的工作过程:
媒体服务器630与用户接入设备620有两个通信进程,这两个进程对应于终端641和终端642。用户接入设备620将端口2的数据包镜像到端口1,并发送到媒体请求响应时间的测试装置610的数据接收端口611。数据接收端口611接收用户接入设备620发送的待分析数据包后,向多线程处理单元612发送所述数据包。多线程处理单元612接收到多个不同目的地址的数据包时,依据多线程的处理方式,并行把所述数据包发送给所述抓包分析单元613。抓包分析单元613捕获并分析数据包,判断是否捕获到媒体请求报文和媒体数据特征码。当所述抓包分析单元613捕获到媒体请求报文时,发出请求时间获取单元614获取发出媒体请求报文的时间。当所述抓包分析单元613捕获到媒体数据特征码时,特征码到达时间获取单元615获取媒体数据特征码到达的时间。根据所述发出请求时间获取单元614获取发出媒体请求报文的时间和所述特征码到达时间获取单元615获取媒体数据特征码到达的时间,媒体请求响应时间计算单元616计算媒体请求响应时间。可以理解的是,本发明同样适用于对超过两个进程的测试工作。
需要说明的是,如果只对一个终端641进行测试,请求响应时间的测试装置610可以不带多线程处理单元612;数据接收端口611接收到用户接入设备发送的待分析数据包后,直接向抓包分析单元613发送所述数据包。
请参考图7,为本发明第二实施例测试装置示意图。一种媒体请求响应时间的测试装置710,包括:抓包分析单元713、发出请求时间获取单元714、特征码到达时间获取单元715、媒体请求响应时间计算单元716、至少一个数据上行端口717、至少一个数据下行端口718/719、镜像处理单元711和多线程处理单元712。
数据上行端口717,用于与媒体服务器进行数据传输。
数据下行端口718/719,用于与终端进行数据传输。
镜像处理单元711,用于复制所述数据上行端口717和所述数据下行端口718/719传输的数据包,向所述抓包分析单元713发送所述数据包。
多线程处理单元712,用于处理所述镜像处理单元711向所述抓包分析单元713发送的数据包,当从所述镜像处理单元711接收到多个不同目的地址的媒体数据时,根据多线程的处理方式,并行把所述数据包发送给所述抓包分析单元713。
抓包分析单元713,用于捕获并分析数据包,判断是否捕获到媒体请求报文和媒体数据特征码。
发出请求时间获取单元714,用于当所述抓包分析单元713捕获到媒体请求报文时,获取发出媒体请求报文的时间。
特征码到达时间获取单元715,用于当所述抓包分析单元713捕获到媒体数据特征码时,获取媒体数据特征码到达的时间。
媒体请求响应时间计算单元716,用于根据所述发出请求时间获取单元714获取发出媒体请求报文的时间和所述特征码到达时间获取单元715获取媒体数据特征码到达的时间,计算媒体请求响应时间。
以下为本实施例测试装置的工作过程:
媒体服务器720与媒体请求响应时间的测试装置710有两个通信进程,这两个进程对应于终端731和终端732。数据上行端口717的数据包镜像到镜像处理单元711。镜像处理单元711向所述多线程处理单元712发送所述数据包。当从所述镜像处理单元711接收到多个不同目的地址的媒体数据时,根据多线程的处理方式,多线程处理单元712并行把所述数据包发送给所述抓包分析单元713。抓包分析单元713捕获并分析数据包,判断是否捕获到媒体请求报文和媒体数据特征码。当所述抓包分析单元713捕获到媒体请求报文时,发出请求时间获取单元714获取发出媒体请求报文的时间。当所述抓包分析单元713捕获到媒体数据特征码时,特征码到达时间获取单元715获取媒体数据特征码到达的时间。根据所述发出请求时间获取单元714获取发出媒体请求报文的时间和所述特征码到达时间获取单元715获取媒体数据特征码到达的时间,媒体请求响应时间计算单元716计算媒体请求响应时间。可以理解的是,本发明同样适用于超过两个进程的测试工作。
需要说明的是,如果只对一个终端731进行测试,请求响应时间的测试装置710可以不带多线程处理单元712;镜像处理单元711复制终端数据上行端口717和数据下行端口718传输的数据包,直接向抓包分析单元713发送所述数据包。
以上对本发明所提供的媒体请求响应时间的测试方法和测试装置进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种媒体请求响应时间的测试方法,其特征在于,包括:
获取发出媒体请求信息的时间;
获取媒体数据特征码到达的时间;
依据所述发出媒体请求信息的时间和所述媒体数据特征码到达的时间,计算媒体请求响应时间。
2.根据权利要求1所述的测试方法,其特征在于,所述媒体请求包括直播请求和/或点播请求。
3.根据权利要求1所述的测试方法,其特征在于,所述获取媒体数据特征码到达的时间前,捕获媒体数据特征码。
4.根据权利要求1所述的测试方法,其特征在于,所述的计算过程为,所述媒体数据特征码到达的时间减去所述发出媒体请求信息的时间。
5.根据权利要求1至4其中之一所述的测试方法,其特征在于,所述特征码为帧内图。
6.一种媒体请求响应时间的测试装置,其特征在于,包括:抓包分析单元、发出请求时间获取单元、特征码到达时间获取单元和媒体请求响应时间计算单元;
抓包分析单元,用于捕获并分析数据包,判断是否捕获到媒体请求报文和媒体数据特征码;
发出请求时间获取单元,用于当所述抓包分析单元捕获到媒体请求报文时,获取发出媒体请求报文的时间;
特征码到达时间获取单元,用于当所述抓包分析单元捕获到媒体数据特征码时,获取媒体数据特征码到达的时间;
媒体请求响应时间计算单元,用于根据所述发出媒体请求报文的时间和所述媒体数据特征码到达的时间,计算媒体请求响应时间。
7.根据权利要求6所述的测试装置,其特征在于,还包括数据接收端口;
数据接收端口,用于接收用户接入设备发送的待分析数据包,向所述抓包分析单元发送所述数据包。
8.根据权利要求7所述的测试装置,其特征在于,还包括多线程处理单元;
多线程处理单元,用于处理所述数据接收端口向所述抓包分析单元发送的数据包,当从所述数据接收端口接收到多个不同目的地址的数据包时,依据多线程的处理方式,并行把所述数据包发送给所述抓包分析单元。
9.根据权利要求6所述的测试装置,其特征在于,还包括至少一个数据上行端口、至少一个数据下行端口和镜像处理单元;
数据上行端口,用于与媒体服务器进行数据传输;
数据下行端口,用于与终端进行数据传输;
镜像处理单元,用于复制所述数据上行端口和所述数据下行端口传输的数据包,向所述抓包分析单元发送所述数据包。
10.根据权利要求9所述的测试装置,其特征在于,还包括多线程处理单元;
多线程处理单元,用于处理所述镜像处理单元向所述抓包分析单元发送的数据包,当从所述镜像处理单元接收到多个不同目的地址的数据包时,根据多线程的处理方式,并行把所述数据包发送给所述抓包分析单元。
CNA2006101386279A 2006-11-08 2006-11-08 媒体请求响应时间的测试方法和测试装置 Pending CN1976306A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CNA2006101386279A CN1976306A (zh) 2006-11-08 2006-11-08 媒体请求响应时间的测试方法和测试装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CNA2006101386279A CN1976306A (zh) 2006-11-08 2006-11-08 媒体请求响应时间的测试方法和测试装置

Publications (1)

Publication Number Publication Date
CN1976306A true CN1976306A (zh) 2007-06-06

Family

ID=38126114

Family Applications (1)

Application Number Title Priority Date Filing Date
CNA2006101386279A Pending CN1976306A (zh) 2006-11-08 2006-11-08 媒体请求响应时间的测试方法和测试装置

Country Status (1)

Country Link
CN (1) CN1976306A (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104253879A (zh) * 2014-09-15 2014-12-31 北京锐安科技有限公司 一种基于ip地址的位置标定方法和装置
CN106302407A (zh) * 2016-08-02 2017-01-04 四川秘无痕信息安全技术有限责任公司 一种监控微信朋友圈发送数据的方法
CN108347473A (zh) * 2017-01-23 2018-07-31 卡西欧计算机株式会社 通信设备、通信系统、通信方法、以及记录介质
CN113688019A (zh) * 2021-08-10 2021-11-23 荣耀终端有限公司 响应时长检测方法及装置

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104253879A (zh) * 2014-09-15 2014-12-31 北京锐安科技有限公司 一种基于ip地址的位置标定方法和装置
CN106302407A (zh) * 2016-08-02 2017-01-04 四川秘无痕信息安全技术有限责任公司 一种监控微信朋友圈发送数据的方法
CN106302407B (zh) * 2016-08-02 2019-05-17 四川秘无痕信息安全技术有限责任公司 一种监控微信朋友圈发送数据的方法
CN108347473A (zh) * 2017-01-23 2018-07-31 卡西欧计算机株式会社 通信设备、通信系统、通信方法、以及记录介质
CN113688019A (zh) * 2021-08-10 2021-11-23 荣耀终端有限公司 响应时长检测方法及装置
CN113688019B (zh) * 2021-08-10 2022-08-09 荣耀终端有限公司 响应时长检测方法及装置

Similar Documents

Publication Publication Date Title
CN1248456C (zh) 传输控制参数产生方法及根据分组特性选择性重发的方法
US8935736B2 (en) Channel switching method, channel switching device, and channel switching system
Turletti et al. Videoconferencing on the Internet
CN1242623C (zh) 视频编码方法、解码方法以及相关的编码器和解码器
KR101458852B1 (ko) 멀티-홉 rtp 스트림에서의 중요 패킷 손실 처리 시스템 및 방법
Diwi et al. Analisis Kualitas Layanan Video Live Streaming pada Jaringan Lokal Universitas Telkom
US20120063462A1 (en) Method, apparatus and system for forwarding video data
US10944973B2 (en) Estimation of video quality of experience on media servers
JP2020184805A (ja) ビデオサービス品質の評価方法及び装置
US9253063B2 (en) Bi-directional video compression for real-time video streams during transport in a packet switched network
CN1910926A (zh) 用于处理视频通信差错的方法和装置
CN1914876A (zh) 定时体验质量的度量
KR20090084826A (ko) 비디오 스트림 내의 아티팩트를 최소화하는 방법, 비디오 스트림의 속성을 변경하는 시스템 및 컴퓨터 판독가능 매체
CN105635636A (zh) 一种视频会议系统及其实现视频图像传输控制的方法
CN1235407C (zh) 从发射机向接收机传输数字化运动图像的方法和系统以及相应的解码器
CN1976306A (zh) 媒体请求响应时间的测试方法和测试装置
CN107707933A (zh) 发送、接收视频流的方法及装置
Ucar et al. Video tester—A multiple-metric framework for video quality assessment over ip networks
WO2010115376A1 (zh) 一种媒体流切换方法、装置和系统
CN114189686A (zh) 视频编码方法、设备、装置及计算机可读存储介质
Bhat et al. Optimization of tune-in and end-to-end delay in DASH broadcast over ROUTE
KR100704116B1 (ko) 멀티미디어 서비스를 위한 다중 실시간 인코딩 방법 및 그서버 장치
Bassey et al. Mitigating the effect of packet losses on real-time video streaming using psnr as video quality assessment metric
Luis et al. Scalable streaming of JPEG 2000 live video using RTP over UDP
Guo et al. Adaptive transmission of split-screen video over wireless networks

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