CN114257858B - 一种基于情感计算的内容同步方法和装置 - Google Patents

一种基于情感计算的内容同步方法和装置 Download PDF

Info

Publication number
CN114257858B
CN114257858B CN202210194781.7A CN202210194781A CN114257858B CN 114257858 B CN114257858 B CN 114257858B CN 202210194781 A CN202210194781 A CN 202210194781A CN 114257858 B CN114257858 B CN 114257858B
Authority
CN
China
Prior art keywords
multicast
video
router
preset
playing
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
CN202210194781.7A
Other languages
English (en)
Other versions
CN114257858A (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.)
Zhejiang Uniview Technologies Co Ltd
Original Assignee
Zhejiang Uniview 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 Zhejiang Uniview Technologies Co Ltd filed Critical Zhejiang Uniview Technologies Co Ltd
Priority to CN202210194781.7A priority Critical patent/CN114257858B/zh
Publication of CN114257858A publication Critical patent/CN114257858A/zh
Application granted granted Critical
Publication of CN114257858B publication Critical patent/CN114257858B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing 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/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network 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/63—Control 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/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network 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/63—Control 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/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本申请实施例公开了一种基于情感计算的内容同步方法和装置，该方法包括：在组播视频播放过程中由每个组播客户端检测是否存在丢包现象；当任意的第一组播客户端检测到存在丢包现象时，由所述第一组播客户端发出自动重传请求，并接收组播视频数据传输路径中一层或多层组播路由器根据预设的协同缓存重传策略发送的重传数据包；在所述第一组播客户端上根据重传数据包对应视频内容的预设属性对该重传数据包对应的组播视频的播放进度进行调节；所述预设属性包括：根据情感计算获取的难易程度和/或重要程度。通过该实施例方案，保证了不丢失视频内容，保证了组播实况教学效果，并减小了由于丢包重传造成的网络负载。

Description

一种基于情感计算的内容同步方法和装置
技术领域
本申请实施例涉及组播技术，尤指一种基于情感计算的内容同步方法和装置。
背景技术
IP（互联网协议）组播通过使用D类IP地址将一份数据同时发送给组播组内的多台主机，这使得它非常适合网上教学等一对多的场景：视频源基于组播面向多客户端主机进行内容播放。但在局域网特别是广域网（如支持组播的M Bone网络）环境下，网络不畅丢包会导致组播视频部分内容丢失。此时，如果直接重传丢失的内容，正常播放，则会导致各个学生之间的进度不一样；如果跳过部分内容，会影响教学效果；如果简单的快进播放，同样会影响教学效果。
在面临组播数据丢包时，视频客户端当前的处理策略一般有两种：1、跳过丢包内容等待网络恢复正常后继续播放；2、通过前向冗余纠错FEC技术恢复丢包。前者因内容缺失而影响业务质量；后者通过丢包侦测利用冗余数据的异或操作恢复数据，冗余数据传输本身增加了网络负载，更易加重网络拥塞。
发明内容
本申请实施例提供了一种基于情感计算的内容同步方法和装置，能够保证不丢失视频内容，保证组播实况教学效果，并减小由于丢包重传造成的网络负载。
本申请实施例提供了一种基于情感计算的内容同步方法，所述方法可以包括：
在组播视频播放过程中由每个组播客户端检测是否存在丢包现象；
当任意的第一组播客户端检测到存在丢包现象时，由所述第一组播客户端发出自动重传请求，并接收组播视频数据传输路径中一层或多层组播路由器根据预设的协同缓存重传策略发送的重传数据包；
在所述第一组播客户端上根据重传数据包对应视频内容的预设属性对该重传数据包对应的组播视频的播放进度进行调节；所述预设属性包括：根据情感计算获取的难易程度和/或重要程度。
在本申请的示例性实施例中，通过该实施例方案，保证了不丢失视频内容，保证了组播实况教学效果，并减小了由于丢包重传造成的网络负载。
本申请实施例还提供了一种基于情感计算的内容同步装置，可以包括处理器和计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令被所述处理器执行时，实现所述的基于情感计算的内容同步方法。
本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的其他优点可通过在说明书以及附图中所描述的方案来实现和获得。
附图说明
附图用来提供对本申请技术方案的理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请的技术方案，并不构成对本申请技术方案的限制。
图1为本申请实施例的基于情感计算的内容同步方法流程图；
图2为本申请实施例的RTP封包结构示意图；
图3为本申请实施例的组播视频传输结构示意图；
图4为本申请实施例的根据预设的协商机制在每个层级的组播路由器之间协商每层组播路由器所需缓存的视频数据的播放时段，并确定每个层级的组播路由器对应的层级数的方法流程图；
图5为本申请实施例的组播视频数据传输路径中一层或多层组播路由器根据预设的协同缓存重传策略发送重传数据包的方法流程图；
图6为本申请实施例的基于情感计算的内容同步装置组成框图。
具体实施方式
本申请描述了多个实施例，但是该描述是示例性的，而不是限制性的，并且对于本领域的普通技术人员来说显而易见的是，在本申请所描述的实施例包含的范围内可以有更多的实施例和实现方案。尽管在附图中示出了许多可能的特征组合，并在具体实施方式中进行了讨论，但是所公开的特征的许多其它组合方式也是可能的。除非特意加以限制的情况以外，任何实施例的任何特征或元件可以与任何其它实施例中的任何其他特征或元件结合使用，或可以替代任何其它实施例中的任何其他特征或元件。
本申请包括并设想了与本领域普通技术人员已知的特征和元件的组合。本申请已经公开的实施例、特征和元件也可以与任何常规特征或元件组合，以形成由权利要求限定的独特的发明方案。任何实施例的任何特征或元件也可以与来自其它发明方案的特征或元件组合，以形成另一个由权利要求限定的独特的发明方案。因此，应当理解，在本申请中示出和/或讨论的任何特征可以单独地或以任何适当的组合来实现。因此，除了根据所附权利要求及其等同替换所做的限制以外，实施例不受其它限制。此外，可以在所附权利要求的保护范围内进行各种修改和改变。
此外，在描述具有代表性的实施例时，说明书可能已经将方法和/或过程呈现为特定的步骤序列。然而，在该方法或过程不依赖于本文所述步骤的特定顺序的程度上，该方法或过程不应限于所述的特定顺序的步骤。如本领域普通技术人员将理解的，其它的步骤顺序也是可能的。因此，说明书中阐述的步骤的特定顺序不应被解释为对权利要求的限制。此外，针对该方法和/或过程的权利要求不应限于按照所写顺序执行它们的步骤，本领域技术人员可以容易地理解，这些顺序可以变化，并且仍然保持在本申请实施例的精神和范围内。
本申请实施例提供了一种基于情感计算的内容同步方法，如图1所示，所述方法可以包括步骤S101-S103：
S101、在组播视频播放过程中由每个组播客户端检测是否存在丢包现象；
S102、当任意的第一组播客户端检测到存在丢包现象时，由所述第一组播客户端发出自动重传请求，并接收组播视频数据传输路径中一层或多层组播路由器根据预设的协同缓存重传策略发送的重传数据包；
S103、在所述第一组播客户端上根据重传数据包对应视频内容的预设属性对该重传数据包对应的组播视频的播放进度进行调节；所述预设属性包括：难易程度和/或重要程度。
在本申请的示例性实施例中，提出了一种丢包后内容完整播放和进度同步的组播实况方案。当其中某个组播客户端A（即第一组播客户端）的视频出现丢包，导致卡顿，为了避免该组播客户端A的学生丢失实况教学内容，通过丢包重传以及播放进度的调节（快进），最终实现播放内容与其他组播客户端同步的目的。
在本申请的示例性实施例中，在线教学组播业务可以包括正常组播业务、收发缓冲、组播丢包侦测及重传、组播客户端倍速播放及内容同步。目前，在线教学的组播业务可通过协议IGMP、PIM-SM/PIM-DM等进行常规配置，在此不展开描述。
在本申请的示例性实施例中，组播缓冲区大小设置属于应用层的实现，本申请实施例对媒体流组播缓存区划分可以包括：组播客户端的接收缓存区、组播视频源服务器的发送缓冲区。可以使用如下参数：往返时延RTT、丢包恢复时间t、组播客户端的缓冲区时间窗口Tcache-c、组播服务器的缓冲区时间窗口Tcache-s，以上单位均为微秒（ms）。
在本申请的示例性实施例中，对于组播客户端的接收缓存区：重传丢包到达时间t在接收缓冲区时间窗口Tcache-c内，丢包才能正常恢复；同时重传时间需要大于往返时延，所以要求RTT≤t≤Tcache-c.，此时Tcache-c缓冲区的大小由以下因素决定：
1、最小缓冲区Tcache-c= | SNlost —SNcur | *Sizeave / Rate，其中SN为RTP（Real-time Transport Protocol，实时传输协议）包头的序列号，SNlost表示第一个丢包的序列号，SNcur为收到最新包的序列号，Sizeave代表数据包的平均大小，Rate是媒体流码率；
2、根据客户需求，缓冲区可在最小Tcache-c的基础上进行放大，但不要超过客户最大容忍度时延△T，虽然缓冲区Tcache-c越大越能提高网络拥堵下的修复效率，但实况时延增大影响系统实时性。
在本申请的示例性实施例中，对于组播视频源服务器的发送缓冲区：发送缓冲区时间窗口Tcache-s计算方法与Tcache-c相似，只是SNlost表示服务器收到ARQ（AutomaticRepeat-reQuest，自动重传请求）请求中最小序列号，SNcur为服务器发送最新包的序列号。
在本申请的示例性实施例中，各个组播客户端收包时，通过解析RTP（实时传输协议）包头的SN来侦测码流丢包情况，并在确定出现丢包现象时要求组播视频源服务器重传。下面可以按是否为丢包组播客户端分为两部分叙述：
1、对于存在丢包现象的组播客户端A：
1）、如图2所示的RTP封包结构，其中，包括IP（互联网协议）包头、UDP（用户数据报协议）包头、RTP（实时传输协议）包头、NALU头、RBSP（原始字节序列层）；RTP载荷NALU。根据RTP包头丢包序号SN或连续丢包序号[SNs,SNe]，生成丢包重传请求ARQ；
2）、组播视频源服务器根据重传方案发送重传的RTP分组；系统可以使用不同的有效载荷类型PT值在相同的RTP流中复用原始RTP分组和重传分组；这些都属于常规的重传方法和机制，本申请实施例不限制其他方式的实现；
3）、组播客户端A收到重传的丢包数据（以RTP头PT值区分重传包和正常包），在插入排序后进行拼帧、解码等操作。
2、对于其他组播成员客户端：
在收到RTP包后解析PT值，确认是否需要重传数据，如果不需要重传数据，可以直接丢弃。
在本申请的示例性实施例中，由以上内容可知，当任意的组播客户端A检测到存在丢包现象时，由组播客户端A发出自动重传请求后，根据预设的重传方案重传数据包。
目前，由于组播仅应用UDP【User Datagram Protocol，用户数据报协议】传输，大多数的组播协议IGMP（因特网组管理协议）v1/v2/v3、PIM-SM（稀疏模式独立组播协议）和PIM-DM（稠密模式独立组播协议）属于三层协议（IGMP-Snooping属于二层协议），均采用半工单向通信，提供的是一种缺乏传输控制的发送服务，并不能实现丢包后纠错和重传，所以FEC（Forward Error Correction，前向纠错）被应用于组播传输的丢包恢复。
该方案的缺点在于：发送方将k个原始数据包、n-k个冗余包所组成的n个数据包一起发送出去。接收者只需要收到k*（k<n，并且k*和k不一定相等）个数据包，便可恢复出原始的k个原始数据包。在网络带宽一定的前提下，对于网上教学或高清影视服务这种流量要求较高的应用场景，冗余编码反而提高了网络拥塞可能性，并且FEC的丢包恢复机制也决定了无法还原连续性丢包。
另外，在组播“尽力而为”传输的服务基础上，通过结合媒体流传输协议，利用RTP包头序列号SN不仅可以网络抖动时对数据包进行排序，而且也可在网络不畅时来检查丢包，通过ARQ的反馈依靠重传丢包来实现可靠组播。
虽然UDP组播具有无法可靠传输的特性，但也为上层应用层各种ARQ实现方案提供了机会，如SRM（Scalable Reliable Multicast，可升级的可靠多播）、MFTP（(MultipleFile Transfer Protocal，多重来源文件传输通讯协议）等。但目前这些可靠组播方案的缺点在于：丢包恢复受限于往返时延RTT（发送时延、传播时延、排队时延、处理时延），故要求RTT≤Tcache，其中Tcache为缓存时间窗口。为了保证数据恢复的成功率或效果，则必然要增加缓冲队列长度，如SRM对于大规模的实时交互应用是很不合适的，所以该技术只能运用到组播回放而无法应用到组播实况教学中。
在本申请的示例性实施例中，基于以上问题，如果组播客户端检测到丢包现象后直接向组播视频源服务器请求重传丢失的内容，会引起全路径的拥塞，如果在网络中间放置缓存服务器，重传的路径也非最优，而且容易引起缓存服务器附近网络的拥塞。为了解决这些问题，本申请实施例方案设置了组播路由器的协同缓存重传策略，即，基于路径上的组播路由器预先协同缓存的组播视频数据对丢失数据包进行重传，这样可以达到重传路径的优化。
在本申请的示例性实施例中，所述方法还可以包括：
在组播视频播放过程中，在组播视频源服务器将组播视频数据包沿组播视频数据传输路径发送时，所述组播视频数据传输路径上的每层组播路由器分别缓存所述组播视频数据包中一个或多个播放时段的视频数据；
其中，组播路由器层和所述组播视频源服务器之间的距离，与该组播路由器层中的路由器中缓存的视频数据对应的播放时段与当前时刻的时间差呈负相关，组播路由器层和所述组播客户端之间的距离，与该组播路由器层中的路由器中缓存的视频数据对应的播放时段与当前时刻的时间差呈正相关。即，越靠近组播视频源服务器的组播路由器层中的路由器中缓存的视频数据对应的播放时段与当前时刻的时间差越大，越靠近组播客户端的组播路由器层中的路由器中缓存的视频数据对应的播放时段与当前时刻的时间差越小。
在本申请的示例性实施例中，为了降低组播路由器的缓存压力，设计了分层协同的缓存方法，即每层的组播路由器只缓存一部分数据，越靠近组播视频源服务器的组播路由器所缓存的数据越老，越靠近组播客户端的组播路由器所缓存的数据越新。这样设计的好处包括：组播客户端大多数时候丢包的数据较少，因此可以就近请求，丢失了很多数据的极端情况才需要向更上层的组播路由器请求重传，这样就可以最大程度的降低网络带宽消耗。
在本申请的示例性实施例中，如图3所示，R31和R32最靠近PC端（组播客户端），可以负责缓存最新的0-10s的视频数据；R21为上一层的组播路由器，可以负责缓存最新的10-20s的视频数据；R1为更上一层的组播路由器，可以负责缓存最新的20-30s的视频数据。对于每个层级的组播路由器具体缓存哪个播放时段的视频数据，可以预先根据整个视频数据的大小、共存在的组播路由器的层级具体定义，在此不予具体播放时段不做限定。
在本申请的示例性实施例中，在所述组播视频数据传输路径上的每层组播路由器分别缓存所述组播视频数据包中一个或多个播放时段的视频数据之前，所述方法还可以包括：
根据预设的协商机制在每个层级的组播路由器之间协商每层组播路由器所需缓存的视频数据的播放时段，并确定每个层级的组播路由器对应的层级数。
在本申请的示例性实施例中，该协商机制可以是基于层级PIM（ProtocolIndependent Multicast，协议无关组播）消息的缓存协商机制。新增一个“层级PIM消息”，即，可以在PIM的Join（加入）消息中增加一个“层级”的字段。
在本申请的示例性实施例中，如图4所示，所述根据预设的协商机制在每个层级的组播路由器之间协商每层组播路由器所需缓存的视频数据的播放时段，并确定每个层级的组播路由器对应的层级数，可以包括S201-S203：
S201、由运行因特网组管理协议IGMP查询器的组播路由器作为最低层级的组播路由器，缓存预先协商好的与所述最低层级的组播路由器对应的播放时段的视频数据，并记录对应的层级为第一层级；
S202、从所述第一层级的组播路由器开始，逐层级向上一层级的组播路由器发送层级协议无关组播PIM消息，所述层级协议无关组播PIM消息中包含发送所述层级协议无关组播PIM消息的路由器所在层级的层级数；
S203、所述上一层级的组播路由器在接收到所述层级协议无关组播PIM消息后，缓存预先协商好的与所述上一层级的组播路由器对应的播放时段的视频数据，将所述上一层级的组播路由器自身对应的层级数在接收到的所述层级协议无关组播PIM消息中包含的层级数基础上加1并进行记录。
在本申请的示例性实施例中，即，所述第一层级的组播路由器缓存第一段预设视频数据后，可以由所述第一层级的组播路由器向上一层级的组播路由器发送第一层级协议无关组播PIM消息，所述第一层级协议无关组播PIM消息中包含所述第一层级的层级数；
由所述第一层级的组播路由器的上一层级的组播路由器接收所述第一层级协议无关组播PIM消息，并在所述第一层级的层级数基础上加1，标记为第二层级，所述第二层级的组播路由器缓存第二段预设视频数据后，可以由所述第二层级的组播路由器向上一层级的组播路由器发送第二层级协议无关组播PIM消息，所述第二层级协议无关组播PIM消息中包含所述第二层级的层级数；……，依次类推，可以确定出每一层级的组播路由器中缓存的视频数据并确定每一层级的组播路由器的层级数。
在本申请的示例性实施例中，例如，运行IGMP查询器的组播路由器扮演最低层级的缓存角色（层级1），负责缓存最新的0-10s的视频数据，当它向上游（即上一层，或上层）发送层级PIM消息时，层级字段填写“1”，上游组播路由器收到来自下游的层级PIM消息（即层级协议无关组播PIM消息），发现里边的层级字段为1，则自身定位为层级2，负责缓存10-20s的视频数据，并向上游组播路由器发送层级PIM消息，其中的层级字段填写“2”，层级2的组播路由器的上游组播路由器依次参照处理，将自己定位层级3，负责缓存20-30s的视频数据。如图3所示，R31（层级1）负责最新的0-10s的视频数据；R21（层级2）负责缓存最新的10-20s的视频数据；R1（层级3）负责缓存最新的20-30s的视频数据。
在本申请的示例性实施例中，所述根据预设的协商机制在每个层级的组播路由器之间协商每层组播路由器所需缓存的视频数据的播放时段，并确定每个层级的组播路由器对应的层级数，还可以包括：
当任意一个组播路由器对应多个层级，并在不同的层级需要缓存不同播放时段的视频数据时，将所述任意一个组播路由器的层级确定为对应的多个层级数中最大的层级数对应的层级，并缓存全部所述不同播放时段的视频数据。
在本申请的示例性实施例中，对于同时扮演多个层级的组播路由器，需要负责缓存多个对应播放时段的视频数据。例如，当R1既要缓存最新的20-30s的视频数据，也要缓存最新的10-20s的视频数据时，对于同一个视频流，则缓存的是最新的10-30s的视频数据。
在本申请的示例性实施例中，所述根据预设的协商机制在每个层级的组播路由器之间协商每层组播路由器所需缓存的视频数据的播放时段，并确定每个层级的组播路由器对应的层级数，还可以包括：
当任意一个组播路由器对应多个层级，定义为第一路由器，与所述第一路由器通过所述组播视频数据传输路径连接的若干下层路由器定义为第二路由器（一个组播路由器可同时作为第一路由器和第二路由器，只是对应关系不同），当所述第一路由器在不同的层级需要缓存不同播放时段的视频数据时，不再缓存所述第二路由器缓存过的视频数据，并由所述第一路由器与第二路由器进行协商，当所述丢失数据包包含所述第二路由器缓存过的视频数据，由所述第二路由器对所缓存的相应播放时段的视频数据进行重传。
在本申请的示例性实施例中，即，当任意一个组播路由器对应多个层级，并在不同的层级需要缓存不同播放时段的视频数据时，检测所述任意一个组播路由器对应的一个或多个下面层级的组播路由器中是否缓存有所述任意一个组播路由器需要缓存的一个或多个不同播放时段的视频数据；
当检测到所述任意一个组播路由器对应的一个或多个下面层级的组播路由器中缓存有所述任意一个组播路由器需要缓存的一个或多个不同播放时段的视频数据时，所述任意一个组播路由器自身不再缓存需要所述任意一个组播路由器缓存的一个或多个不同播放时段的视频数据，并由所述任意一个组播路由器与所述一个或多个下面层级的组播路由器进行协商，当所述丢失数据包包含所述一个或多个下面层级的组播路由器所缓存的相应播放时段的视频数据时，由所述一个或多个下面层级的组播路由器对所缓存的相应播放时段的视频数据进行重传。
在本申请的示例性实施例中，之所以部分组播路由器需要缓存多个层级的数据，是因为它同时扮演了多个层级的缓存角色，为了进一步降低缓存压力，本申请实施例还提出了跨分支协同的重传机制。
在本申请的示例性实施例中，即，当一个多层级的组播路由器发现自己需要缓存（S1,G1）组播流的多个层级的视频数据时，可以向下游（即下一层，或下层）的组播路由器协商，必要时向下游的组播路由器请求发送重传数据。
在本申请的示例性实施例中，例如，当R1收到来自两个下游组播路由器的层次PIM消息，对于组播流（S1，G1）需要缓存10-20s和20-30s的视频数据时，R1可以发送消息给R21，协商请R21负责在必要时重传缓存的10-20s的视频数据。
在本申请的示例性实施例中，基于以上的协商机制，组播客户端发起自动重传请求后，可以由组播路由器自动根据协同缓存重传策略发送重传数据包，下面对协同缓存重传策略的内容进行详细介绍（即组播视频数据传输路径中一层或多层组播路由器根据预设的协同缓存重传策略发送重传数据包的详细方法）。
在本申请的示例性实施例中，如图5所示，在所述第一组播客户端发出所述自动重传请求以后，所述组播视频数据传输路径中一层或多层组播路由器根据预设的协同缓存重传策略发送重传数据包，可以包括步骤S301-S302：
S301、从最低层级的组播路由器开始，逐层级向所述组播视频数据传输路径中每层组播路由器的上层的组播路由器发送所述自动重传请求；其中，所述自动重传请求包含：丢失数据包对应的视频数据的播放时段时间戳以及所述第一组播客户端的网络协议IP地址；
S302、在任意一个层级的组播路由器包含所述丢失数据包对应的视频数据时，由该组播路由器将所述丢失数据包对应的视频数据进行重传，直至所述第一组播客户端获取到所述丢失数据包对应的全部播放时段的视频数据。
在本申请的示例性实施例中，例如，在组播视频播放过程中，当PC1发现丢失了最近的0-25s的视频数据，则向上游组播路由器发送自动重传请求，以请求对丢包视频数据进行重传，消息内部标记所丢失数据的两端时间戳（即播放时段时间戳），以及请求者PC1的IP地址；R31收到请求消息，发现需要重传自己负责缓存的最新的0-10s的视频数据，则将这段视频数据重传给PC1，并继续将自动重传请求消息转发给上游路由器R21，自动重传请求消息中内含请求者PC1的IP地址；R21发现需要重传自己负责缓存的最新的10-20s的视频数据，则将这段视频数据重传给PC1，并继续将自动重传请求消息转发给上游组播路由器R1，自动重传请求消息中内含请求者PC1的IP地址；R1发现需要自己负责缓存的最新的20-25s的视频数据，则将这段视频数据重传给PC1，至此，使得丢失数据包对应的全部视频数据进行重传。
在本申请的示例性实施例中，所述组播视频数据传输路径中一层或多层组播路由器根据预设的协同缓存重传策略发送重传数据包，还可以包括：
当任意一个组播路由器对应多个层级时，所述任意一个组播路由器接收到所述自动重传请求后，获取所述任意一个组播路由器自身所包含的所述丢失数据包对应的播放时段的视频数据，并进行重传；对于所述任意一个组播路由器自身未包含的所述丢失数据包对应的播放时段的视频数据，将所述自动重传请求发送给所述任意一个组播路由器对应的一个或多个下面层级的组播路由器，由所述一个或多个下面层级的组播路由器对所述一个或多个下面层级的组播路由器自身包含的所述丢失数据包对应的播放时段的视频数据进行重传。
在本申请的示例性实施例中，基于前述的跨分支协同的重传机制，具体地，例如，当PC3丢失了最新的0-25s的视频数据时，将自动重传请求消息发送给R22，消息中内含请求者PC3的IP地址；R22将自己负责缓存的最新的0-10s的视频数据重传给PC3，同时将自动重传请求消息发送给R1，消息中内含请求者PC3的IP地址；R1将自己负责缓存的最新的20-25s的视频数据发送给PC3，并将自动重传请求消息发送给R21，消息中内含请求者PC3的IP地址；R21将最新的10-20s的视频数据发送给PC3。
在本申请的示例性实施例中，在所述组播视频数据传输路径中一层或多层组播路由器根据预设的协同缓存重传策略发送重传数据包之前，所述方法还可以包括：
由所述组播视频源服务器对待重传的组播视频根据所述预设属性进行帧剪裁；
其中，所述预设属性为难和/或重要的组播视频段保留全部帧，所述预设属性为不难和/或不重要的组播视频段保留I帧，删除P帧。
在本申请的示例性实施例中，为了减少重传的数据量，组播视频源服务器可以根据预先确定出来的待重传的视频数据的预设属性对待重传的视频数据可以进行裁剪。
在本申请的示例性实施例中，该预设属性可以包括但不限于：难易程度和/或重要程度；其中，该难易程度对应的具体属性可以为难和不难（易），该重要程度对应的具体属性可以为重要和不重要。对于一段视频内容的具体属性的判断，在后序内容中将详细介绍。
在本申请的示例性实施例中，对于任意一段确定了预设属性的视频内容，在进行重传之前，可以对对容易的视频内容只保留I帧的数据，删除P帧的数据，减少重传数据包；而对较难的视频内容的视频数据可以正常重传。具体实现方案可以包括：
1、组播视频源服务器对丢包区间[SNs , SNe]重传数据的剪裁和封装：
1）获取丢包区间[SNs,SNe]的内容难易度：可以通过该SN区间[SNs,SNe]所属Frame->所属GoP关系，将图片组粒度下{GoP, Diff}映射转换为多个丢包内容的难度；
2）重传全部音频数据，使得声音不至于卡顿；
3）封装和剪裁重传视频数据（可根据难度值只重传I帧数据）：
（1）查找组播视频源服务器发送缓存中的[SNs , SNe]数据包，通过解析NALU头内nal_unit_type字段找出需重传的I帧、B帧、P帧，可以参见图2所示；
（2）对于难度等级Diff低，属于简单的GoP，只重传I帧；即，只对GoP内的I帧重新封装；封装时修改RTP头有效载荷类型为PTe；
（3）对于难度等级Diff高，属于难的GoP，全部重传；即，对GoP内I、B、P帧全部重新封装；封装时修改RTP头有效载荷类型为PTh；
2、组播客户端A对重传数据包的解码：由于组播视频源服务器发送的都是I帧数据，所以不会出现花屏；音频数据是全部重传，播放效果上只有快播不会有卡顿。
在本申请的示例性实施例中，通过对重传数据的剪裁，不仅减少了重传数据量（裁剪非关键帧可节约大概1/3数据传输量），而且并不会影响对组播客户端的教学效果。
在本申请的示例性实施例中，所述在所述第一组播客户端上根据重传数据包对应视频内容的预设属性对该重传数据包对应的组播视频的播放进度进行调节，可以包括：
当所述重传数据包对应视频内容的难易程度为难时，将所述重传数据包对应的组播视频正常播放或按照第一倍率进行快速播放；当所述重传数据包对应视频内容的难易程度为易时，将所述重传数据包对应的组播视频按照第二倍率进行快速播放；所述第二倍率大于所述第一倍率；和/或，
当所述重传数据包对应视频内容的重要程度为重要时，将所述重传数据包对应的组播视频正常播放或按照第三倍率进行快速播放；当所述重传数据包对应视频内容的难易程度为不重要时，将所述重传数据包对应的组播视频按照第四倍率进行快速播放；所述第四倍率大于所述第三倍率。
在本申请的示例性实施例中，丢包的组播客户端A对收到的重传数据包，可以从丢包内容开始以设定倍速播放，以加快与其它各组播客户端的播放内容同步进度。
在本申请的示例性实施例中，在发生丢包前（如系统刚启用时），每个组播客户端收到组播视频数据都会经过排序、拼帧、解码和显示正常处理；组播客户端记录收到最新SNcur与缓冲内解码序列号SNde之间的正常序号差值△SN，该差值△SN可作为组播客户端进入同步播放组播源内容的依据。
在本申请的示例性实施例中，对于丢包重传的[SNs ,SNe]数据：如果RTP头解析出来视频为重传PT类型（PT值可以不同，以代表不同的难易程度和/或重要程度），则为了抵消重传消耗的时间，可以加快播放速度，如2X倍速。
在本申请的示例性实施例中，在收到SNe之后可以正常传输的数据包，既可对正常接收的RTP数据包可按常速播放；也可为加快同步进度，组播客户端A通过判断缓冲区内|SNcur - SNde|≤△SN的差值要求，对组播视频进行倍速播放以此实现快速内容同步。
在本申请的示例性实施例中，通过上述方案，组播客户端A的视频出现丢包，为避免该组播客户端A的学生丢失实况教学内容，通过丢包重传以及播放进度的调节（快进），最终可实现播放内容与其他组播客户端同步的目的。
在本申请的示例性实施例中，为了避免快进播放导致重要和较难内容的被快速播放，可以预先对播放内容的预设属性进行判断，使得组播客户端A进行容易内容的快速播放、较难内容的正常或慢速播放，从而保证了实况组播教学的效果，解决组播教学的传输不可靠以及教学内容同步不理想的问题。
在本申请的示例性实施例中，在所述第一组播客户端上根据重传数据包对应视频内容的预设属性对该重传数据包对应的组播视频的播放进度进行调节之前，可以通过以下任意一种或多种方式确定出所述重传数据包对应视频内容的预设属性：
方式一、由多个组播客户端中除所述第一组播客户端以外的其它组播客户端采集学生表情，由所述第一组播客户端根据所述学生表情分析所述重传数据包对应的视频内容的预设属性；
方式二、由所述第一组播客户端根据多个组播客户端自行判断出的整个组播视频中每段预设长度的视频内容的预设属性的整合结果，确定所述重传数据包对应的视频内容的预设属性；以及，
方式三、由组播视频源服务器根据预设的属性映射表获取丢失数据包对应的播放时段的视频数据的预设属性，并将获取的丢失数据包对应的播放时段的视频数据的预设属性的信息发送给所述第一组播客户端；所述属性映射表包含根据预设的粒度级别设置的组播视频中不同的视频内容与不同的预设属性的对应关系；所述粒度级别包括：帧粒度级、图片组粒度级或播放时段粒度级。
在本申请的示例性实施例中，下面对方式一、方式二和方式三分别进行详细说明。
方式一、
在本申请的示例性实施例中，在方式三中组播视频源服务器的压力较大的情况下，对教学内容难易程度的判断可改进为通过多个组播客户端中除所述第一组播客户端以外的其它组播客户端采集学生表情判断重传数据包对应的难易程度和/或重要程度。
情感计算是与情感相关，来源于情感或能够对情感施加影响的计算；情感计算的目的是通过赋予计算机识别、理解、表达和适应人的情感的能力来建立和谐人机环境，并使计算机具有更高的、全面的智能。
在本申请的示例性实施例中，人们可以通过面部表情来表达情感，因此本申请实施例方案可以通过面部表情的识别与分析实现情感计算，获取所述的预设属性。在组播客户端A丢包重传期间，可以利用其它组播客户端的摄像头来采集、识别学员的面部表情。当前有很多面部表情识别FER的深度神经网络算法，如C3D、CNN-LSTM等，对于所采用的具体面部表情识别算法在此不做限定。
在本申请的示例性实施例中，根据面部表情识别结果（如轻松、皱眉/中性等）将当前课程内容转换为学员接受的难易程度Diffi∈[0,1]，即，可以采用打分制，0分表示容易，1分表示最难；紧邹眉头表示难，1分，表情很轻松表示容易，0分；其主要实现步骤可以：组播客户端的组播流可以经过收包、拼帧、解码、送显几个过程，RTP头在拼帧的时候去除；在组播流拼帧时记录下帧Fi对应的RTP头的起始序号SNs和结尾SNe；根据对Fi帧的识别结果Diffi，为数据序号[SNs , SNe]赋值难易度Diff。
在本申请的示例性实施例中，组播客户端A收到其它各个组播客户端反馈的SNi（某段视频数据的数据序号）和相应的Diffi（该段视频的难易程度）的对应关系表，通过综合分析，给出重传数据包的视频内容SN的难易度Diff。分析的方法可采用平均值法、中值法等方式来计算最终分值，组播客户端A也可调大粒度，例如，将数据序号粒度级{SN, Diff}的关系经综合后映射为帧粒度级{Frame, Diff}、图片组粒度级{GoP，Diff}等。
方式二：
在本申请的示例性实施例中，在方式三中组播视频源服务器的压力较大的情况下，对教学内容难易程度的判断可改进为由每个组播客户端以组播的方式向除自身以外的其它每个组播客户端发送各个播放时段的视频内容的难易程度和/或重要程度等信息，发送的目的地址为当前组播视频的组播地址，这样使得其它组播客户端都可以收到，以使得每个组播客户端可以对其它组播客户端的判断结果进行整合，获取关于每段视频内容对应的预设属性的整合结果。
在本申请的示例性实施例中，获取多个组播客户端自行判断出的整个组播视频中每段预设长度的视频内容的预设属性的整合结果，可以包括：
每个组播客户端对所述每段预设长度的视频内容的预设属性进行判断，并将判断结果以组播的形式发送给除自身以外的其它组播客户端；
针对每段预设长度的视频内容，每个组播客户端从收到的该段预设长度的视频内容的多个判断结果中确定出该段预设长度的视频内容对应的不同属性，并将判断结果数量最多的属性作为该段预设长度的视频内容对应的预设属性；
每个组播客户端将整个组播视频中全部预设长度的视频内容对应的预设属性作为所述整合结果。
在本申请的示例性实施例中，对于任意一个组播客户端X，在收到针对每段视频内容的预设属性的判断结果时，最终确定该段视频内容的预设属性的方法可以是，基于少数服从多数的原则进行判断，例如，针对一段视频内容，如果收到3个组播客户端判断该段视频内容的难易程度为易，收到9个组播客户端判断该段视频内容的难易程度为难，则最终判定该段视频内容的难易程度为难。
在本申请的示例性实施例中，判断内容难易的时间段划分长度（即上述的预设长度）可以由管理员根据不同应用场景进行自定义。
在本申请的示例性实施例中，为了保证各个组播客户端难度判定时刻的统一性，各个组播客户端之间可通过NTP协议进行时间同步，例如，组播客户端在每1秒的开始点分析学生的表情，并在每1秒的结束点向其它组播客户端反馈表情分值。
在本申请的示例性实施例中，各个组播客户端可以将面部表情映射为各播放时段的视频内容的难易程度和/或重要程度。同样可将映射关系综合，形成从帧粒度级{Frame,Diff}、秒粒度级{Sec, Diff}到图片组粒度级{GoP，Diff}的映射关系；判断视频内容难易的单位长度可以由管理员设置，为上下文统一描述，以下仍以图片组GoP粒度级进行叙述。
在本申请的示例性实施例中，各个组播客户端可以按管理员设定的周期将图片组粒度级{GoP，Diff}的映射关系通过系统设置的组播地址组播到其它组播客户端；其它组播客户端根据收到的难易程度和/或重要程度反馈，按少数服从多数的投票表决，形成该时段内容的难易度结果。
在本申请的示例性实施例中，基于以上方案，组播客户端A在收到丢包重传的[SNs, SNe]数据包后，查找该SN区间所属Frame->GoP，结合{GoP, Diff}内的映射关系，获得丢包时段的视频内容对应的难度级别Diff，组播客户端A可以根据该难度级别Diff调整该丢包视频内容以及后续视频内容的播放速度。
在本申请的示例性实施例中，组播客户端A在播放进度仍落后的前提下，可根据持续获得的其它组播客户端对视频内容的预设属性的反馈信息，对后续正常收包内容也进行快进播放。直到组播客户端A通过判断缓冲区内|SNcur - SNde|的差值落入△SN的要求之内。
方式三、
在本申请的示例性实施例中，可以通过组播视频源服务器来确定每段视频内容的预设属性，预先获取预设的属性映射表，从而根据该预设的属性预设表确定丢失数据包对应的视频内容的预设属性，发送给组播客户端A。
在本申请的示例性实施例中，获取所述属性映射表可以包括：
在组播视频播放过程中通过组播客户端实时采集预设的学生表情，并对采集到的不同的学生表情进行打分，由所述组播客户端将不同的视频内容对应的学生表情的打分发送给所述组播视频源服务器，由所述组播视频源服务器按照预设算法对不同的视频内容对应的学生表情的打分进行分析，获取所述属性映射表；和/或，
由所述组播视频源服务器采集并保存专家针对不同的视频内容设置的预设属性，并生成所述属性映射表。
在本申请的示例性实施例中，获取属性映射表可以包含至少两个方案，第一种可以是通过对组播客户端采集的学生表情进行分析获得，第二种可以是直接通过专家打分获得。由于第二种方案较简单，下面对第一种方案进行详细说明。
在本申请的示例性实施例中，可以利用组播客户端的摄像头来采集、识别学员的面部表情。当前有很多面部表情识别FER的深度神经网络算法，如C3D、CNN-LSTM等，对于所采用的具体面部表情识别算法在此不做限定。
在本申请的示例性实施例中，根据面部表情识别结果（如轻松、皱眉/中性等）将当前课程内容转换为学员接受的难易程度Diffi∈[0,1]，即，可以采用打分制，0分表示容易，1分表示最难；紧邹眉头表示难，1分，表情很轻松表示容易，0分。其主要实现步骤可以：组播客户端的组播流可以经过收包、拼帧、解码、送显几个过程，RTP头在拼帧的时候去除；在组播流拼帧时记录下帧Fi对应的RTP头的起始序号SNs和结尾SNe；根据对Fi帧的识别结果Diffi，为数据序号[SNs , SNe]赋值难易度Diff。
在本申请的示例性实施例中，为了保证各个组播客户端难度判定时刻的统一性，组播视频源服务器与各个组播客户端可通过NTP协议进行时间同步，例如，组播客户端在每1秒的开始点分析学生的表情，并在每1秒的结束点向组播视频源服务器反馈表情分值。
在本申请的示例性实施例中，组播视频源服务器收到各个组播客户端反馈的SNi（某段视频数据的数据序号）和相应的Diffi（该段视频的难易程度）的对应关系表，通过综合分析，给出各时刻视频内容SN的难易度Diff。分析的方法可采用平均值法、中值法等方式来计算最终分值，组播服务器也可调大粒度，例如，将数据序号粒度级{SN, Diff}的关系经综合后映射为帧粒度级{Frame, Diff}、图片组粒度级{GoP，Diff}等。
在本申请的示例性实施例中，组播视频源服务器根据ARQ请求，查询丢包区间[SNs, SNe]以及到最新发包SNcur内容的难易程度信息，将该信息和重传数据包发往组播客户端A。具体实现需考虑如下两部分：
1、对于丢包区间[SNs , SNe]：重传丢包和Diff信息。
1）根据ARQ请求内包含的SN区间，查找{GoP, Diff}的映射，反映丢包及内容的难度；
2）服务器封装和重传数据：根据难易程度（或称难度等级）Diff，在封装时修改RTP头有效载荷类型为PTh/PTe，其中h代表Hard，e为Easy类型；
2、对于未丢包区间[SNe+1, SNcur]：只发送Diff信息。
在本申请的示例性实施例中，通过封装RTP头有效载荷类型为PTe/PTh 来加快这段码流的播放速度，RTP载荷为空数据即可。
在本申请的示例性实施例中，组播客户端对于丢包重传数据[SNs , SNe]：
如果RTP头解析出来视频为PTe类型，则加快播放速度，如2X倍速；
如果RTP头解析出来视频为PTh类型，则按正常倍速播放。
在本申请的示例性实施例中，组播客户端对于[SNe+1, SNcur]区间的视频数据，对解析出的PTe类型的RTP数据也加快播放速度。
在本申请的示例性实施例中，为使组播客户端A与其他组播客户端尽快同步，组播视频源服务器可向组播客户端A持续发送Diff信息供其播放加速：
1）组播视频源服务器发送RTP空载荷数据包，仅携带Diff信息，封装同上；
2）组播视频源服务器发送Diff信息的终止条件：直到收到组播客户端A反馈的SNi和Diffi的对应关系表与其他组播客户端反馈的SN相同，此时可认为各个组播客户端缓冲区内在拼帧/解码相同帧数据，以经实现同步播放。
在本申请的示例性实施例中，所述方法还可以包括：
在组播视频播放过程中，由每个组播客户端采集学生听课期间的表情和行为；
当采集到的表情符合预设表情和/或采集到的行为符合预设行为时，发出预设提醒，并将学生做出所述预设表情和/或所述预设行为时段内播放的视频内容进行重新播放；
根据重新播放的视频内容的后续视频内容的预设属性，对所述后续视频内容的播放速度进行调整。
在本申请的示例性实施例中，该预设表情可以包括但不限于：走神、睡觉、嬉笑；该预设行为包括但不限于：打闹、打电话、聊天、离开。
在本申请的示例性实施例中，该预设表情可以通过预先建立并训练好的表情检测模型来检测，该预设行为可以通过预先建立并训练好的行为检测模型来检测。
在本申请的示例性实施例中，除了通过判断丢包数据的视频内容的预设属性这种方式来调节组播客户端播放速度之外，本申请实施例提出了结合摄像机对当前学员状态的识别，来确定最终的播放速度；具体方案可以包括：
如果判断任意的组播客户端X前的学员处于出神发呆的状态，则组播客户端记录该状态对应的播放视频时段[SNs , SNe]，同时通过摄像头给予声光提醒或屏幕警示；
组播客户端可以对学员发呆时段的内容重新播放，播放速度综合内容难易度和学员此刻状态决定；只有在学员状态佳或正常情形下，且此时的视频内容容易时才快进播放。
在本申请的示例性实施例中，重新播放和丢包重传均会导致缓冲区内数据变长，需不断通过对容易内容加速播放追赶进度，直到与其他组播客户端播放进度同步，判断同步依据同上。
在本申请的示例性实施例中，本申请实施例方案保证了每个组播客户端在接收实时视频内容时，不会因为网络丢包而丢失内容；在保证组播实况教学效果的前提下，不仅减少了丢包重传数据量，也解决了组播只能应用用于回放而无法实况的问题。
本申请实施例还提供了一种基于情感计算的内容同步装置1，如图6所示，可以包括处理器11和计算机可读存储介质12，所述计算机可读存储介质12中存储有指令，当所述指令被所述处理器11执行时，实现所述的基于情感计算的内容同步方法。
在本申请的示例性实施例中，前述的基于情感计算的内容同步方法实施例中的任意实施例均可以应用于该基于情感计算的内容同步装置实施例中，在此不再一一赘述。
在本申请的示例性实施例中，基于情感计算的内容同步装置1可以包括多个不同的功能模块，分别设置于组播视频源服务器、组播路由器和/或组播客户端等。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质（或非暂时性介质）和通信介质（或暂时性介质）。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息（诸如计算机可读指令、数据结构、程序模块或其他数据）的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于 RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘（DVD）或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

Claims (12)

1.一种基于情感计算的内容同步方法，其特征在于，所述方法包括：
在组播视频播放过程中由每个组播客户端检测是否存在丢包现象；
当任意的第一组播客户端检测到存在丢包现象时，由所述第一组播客户端发出自动重传请求，并接收组播视频数据传输路径中一层或多层组播路由器根据预设的协同缓存重传策略发送的重传数据包；
在所述第一组播客户端上根据重传数据包对应视频内容的预设属性对该重传数据包对应的组播视频的播放进度进行调节；所述预设属性包括：根据情感计算获取的难易程度和/或重要程度；
其中，所述难易程度包括：难和不难；所述重要程度包括：重要和不重要；
所述在所述第一组播客户端上根据重传数据包对应视频内容的预设属性对该重传数据包对应的组播视频的播放进度进行调节包括：
当所述重传数据包对应视频内容的难易程度为难时，将所述重传数据包对应的组播视频正常播放或按照第一倍率进行快速播放；当所述重传数据包对应视频内容的难易程度为不难时，将所述重传数据包对应的组播视频按照第二倍率进行快速播放；所述第二倍率大于所述第一倍率；和/或，
当所述重传数据包对应视频内容的重要程度为重要时，将所述重传数据包对应的组播视频正常播放或按照第三倍率进行快速播放；当所述重传数据包对应视频内容的难易程度为不重要时，将所述重传数据包对应的组播视频按照第四倍率进行快速播放；所述第四倍率大于所述第三倍率。
2.根据权利要求1所述的基于情感计算的内容同步方法，其特征在于，所述方法还包括：
在组播视频播放过程中，当组播视频源服务器将组播视频数据包沿组播视频数据传输路径发送时，所述组播视频数据传输路径上的每层组播路由器分别缓存所述组播视频数据包中一个或多个播放时段的视频数据；
其中，组播路由器层和所述组播视频源服务器之间的距离，与该组播路由器层中的路由器中缓存的视频数据对应的播放时段与当前时刻的时间差呈负相关，组播路由器层和所述组播客户端之间的距离，与该组播路由器层中的路由器中缓存的视频数据对应的播放时段与当前时刻的时间差呈正相关。
3.根据权利要求2所述的基于情感计算的内容同步方法，其特征在于，在所述组播视频数据传输路径上的每层组播路由器分别缓存所述组播视频数据包中一个或多个播放时段的视频数据之前，所述方法还包括：
根据预设的协商机制在每个层级的组播路由器之间协商每层组播路由器所需缓存的视频数据的播放时段，并确定每个层级的组播路由器对应的层级数。
4.根据权利要求3所述的基于情感计算的内容同步方法，其特征在于，所述根据预设的协商机制在每个层级的组播路由器之间协商每层组播路由器所需缓存的视频数据的播放时段，并确定每个层级的组播路由器对应的层级数，包括：
由运行因特网组管理协议IGMP查询器的组播路由器作为最低层级的组播路由器，缓存预先协商好的与所述最低层级的组播路由器对应的播放时段的视频数据，并记录对应的层级为第一层级；
从所述第一层级的组播路由器开始，逐层级向上一层级的组播路由器发送层级协议无关组播PIM消息，所述层级协议无关组播PIM消息中包含发送所述层级协议无关组播PIM消息的路由器所在层级的层级数；
所述上一层级的组播路由器在接收到所述层级协议无关组播PIM消息后，缓存预先协商好的与所述上一层级的组播路由器对应的播放时段的视频数据，将所述上一层级的组播路由器自身对应的层级数在接收到的所述层级协议无关组播PIM消息中包含的层级数基础上加1并进行记录。
5.根据权利要求4所述的基于情感计算的内容同步方法，其特征在于，所述根据预设的协商机制在每个层级的组播路由器之间协商每层组播路由器所需缓存的视频数据的播放时段，并确定每个层级的组播路由器对应的层级数，还包括：
当任意一个组播路由器对应多个层级，并在不同的层级需要缓存不同播放时段的视频数据时，将所述任意一个组播路由器的层级确定为对应的多个层级数中最大的层级数对应的层级，并缓存全部所述不同播放时段的视频数据。
6.根据权利要求4所述的基于情感计算的内容同步方法，其特征在于，所述根据预设的协商机制在每个层级的组播路由器之间协商每层组播路由器所需缓存的视频数据的播放时段，并确定每个层级的组播路由器对应的层级数，还包括：
当任意一个组播路由器对应多个层级，定义为第一路由器，与所述第一路由器通过所述组播视频数据传输路径连接的若干下层路由器定义为第二路由器，当所述第一路由器在不同的层级需要缓存不同播放时段的视频数据时，不再缓存所述第二路由器缓存过的视频数据，并由所述第一路由器与第二路由器进行协商，当丢失数据包包含所述第二路由器缓存过的视频数据，由所述第二路由器对所缓存的相应播放时段的视频数据进行重传。
7.根据权利要求1所述的基于情感计算的内容同步方法，其特征在于，在所述第一组播客户端发出所述自动重传请求以后，所述组播视频数据传输路径中一层或多层组播路由器根据预设的协同缓存重传策略发送重传数据包，包括：
从最低层级的组播路由器开始，逐层级向所述组播视频数据传输路径中每层组播路由器的上层的组播路由器发送所述自动重传请求；其中，所述自动重传请求包含：丢失数据包对应的视频数据的播放时段时间戳以及所述第一组播客户端的网络协议IP地址；
在任意一个层级的组播路由器包含所述丢失数据包对应的视频数据时，由该组播路由器将所述丢失数据包对应的视频数据进行重传，直至所述第一组播客户端获取到所述丢失数据包对应的全部播放时段的视频数据。
8.根据权利要求1所述的基于情感计算的内容同步方法，其特征在于，
在所述组播视频数据传输路径中一层或多层组播路由器根据预设的协同缓存重传策略发送重传数据包之前，所述方法还包括：
由所述组播视频源服务器对待重传的组播视频根据所述预设属性进行帧剪裁；
其中，所述预设属性为难和/或重要的组播视频段保留全部帧，所述预设属性为不难和/或不重要的组播视频段保留I帧，删除P帧。
9.根据权利要求1所述的基于情感计算的内容同步方法，其特征在于，在所述第一组播客户端上根据重传数据包对应视频内容的预设属性对该重传数据包对应的组播视频的播放进度进行调节之前，通过以下任意一种或多种方式确定出所述重传数据包对应视频内容的预设属性：
由多个组播客户端中除所述第一组播客户端以外的其它组播客户端采集学生表情，由所述第一组播客户端根据所述学生表情分析所述重传数据包对应的视频内容的预设属性；
由所述第一组播客户端根据多个组播客户端自行判断出的整个组播视频中每段预设长度的视频内容的预设属性的整合结果，确定所述重传数据包对应的视频内容的预设属性；以及，
由组播视频源服务器根据预设的属性映射表获取丢失数据包对应的播放时段的视频数据的预设属性，并将获取的预设属性的信息发送给所述第一组播客户端；所述属性映射表包含根据预设的粒度级别设置的组播视频中不同的视频内容与不同的预设属性的对应关系；所述粒度级别包括：帧粒度级、图片组粒度级或播放时段粒度级。
10.根据权利要求9所述的基于情感计算的内容同步方法，其特征在于，获取多个组播客户端自行判断出的整个组播视频中每段预设长度的视频内容的预设属性的整合结果，包括：
每个组播客户端对所述每段预设长度的视频内容的预设属性进行判断，并将判断结果以组播的形式发送给除自身以外的其它组播客户端；
针对每段预设长度的视频内容，每个组播客户端从收到的该段预设长度的视频内容的多个判断结果中确定出该段预设长度的视频内容对应的不同属性，并将判断结果数量最多的属性作为该段预设长度的视频内容对应的预设属性；
每个组播客户端将整个组播视频中全部预设长度的视频内容对应的预设属性作为所述整合结果。
11.根据权利要求1所述的基于情感计算的内容同步方法，其特征在于，所述方法还包括：
在组播视频播放过程中，由每个组播客户端采集学生听课期间的表情和行为；
当采集到的表情符合预设表情和/或采集到的行为符合预设行为时，发出预设提醒，并将学生做出所述预设表情和/或所述预设行为时段内播放的视频内容进行重新播放；
根据重新播放的视频内容的后续视频内容的预设属性，对所述后续视频内容的播放速度进行调整。
12.一种基于情感计算的内容同步装置，包括处理器和计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令被所述处理器执行时，实现如权利要求1-11任意一项所述的基于情感计算的内容同步方法。
CN202210194781.7A 2022-03-02 2022-03-02 一种基于情感计算的内容同步方法和装置 Active CN114257858B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210194781.7A CN114257858B (zh) 2022-03-02 2022-03-02 一种基于情感计算的内容同步方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210194781.7A CN114257858B (zh) 2022-03-02 2022-03-02 一种基于情感计算的内容同步方法和装置

Publications (2)

Publication Number Publication Date
CN114257858A CN114257858A (zh) 2022-03-29
CN114257858B true CN114257858B (zh) 2022-07-19

Family

ID=80797214

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210194781.7A Active CN114257858B (zh) 2022-03-02 2022-03-02 一种基于情感计算的内容同步方法和装置

Country Status (1)

Country Link
CN (1) CN114257858B (zh)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103310669A (zh) * 2013-06-09 2013-09-18 深圳市拓莱思科技有限公司 一种用于互动教学的数据传输方法及系统
CN106790576A (zh) * 2016-12-27 2017-05-31 深圳市汇龙建通实业有限公司 一种互动桌面同步方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6148005A (en) * 1997-10-09 2000-11-14 Lucent Technologies Inc Layered video multicast transmission system with retransmission-based error recovery
US7093028B1 (en) * 1999-12-15 2006-08-15 Microsoft Corporation User and content aware object-based data stream transmission methods and arrangements
EP1901525A1 (en) * 2006-09-15 2008-03-19 THOMSON Licensing File repair method for a content distribution system
CN100518332C (zh) * 2007-01-12 2009-07-22 西安交通大学 一种多路媒体同步呈现控制方法
JP2008211579A (ja) * 2007-02-27 2008-09-11 Nippon Telegr & Teleph Corp <Ntt> 映像品質推定方法および映像通信システム
JP4787210B2 (ja) * 2007-05-30 2011-10-05 日本電信電話株式会社 映像品質推定方法、装置、およびプログラム
US9325951B2 (en) * 2008-03-03 2016-04-26 Avigilon Patent Holding 2 Corporation Content-aware computer networking devices with video analytics for reducing video storage and video communication bandwidth requirements of a video surveillance network camera system
CN101668027B (zh) * 2008-09-04 2013-04-24 中国电信股份有限公司 多媒体内容的提供方法、系统和客户端
CN101588494B (zh) * 2009-06-30 2011-09-21 华为技术有限公司 一种媒体流处理方法及通讯系统以及相关设备
US9462230B1 (en) * 2014-03-31 2016-10-04 Amazon Technologies Catch-up video buffering
WO2016110275A1 (zh) * 2015-01-08 2016-07-14 上海交通大学 一种基于媒体内容的fec机制
CN107193841B (zh) * 2016-03-15 2022-07-26 北京三星通信技术研究有限公司 媒体文件加速播放、传输及存储的方法和装置
US10170153B2 (en) * 2017-03-20 2019-01-01 International Business Machines Corporation Auto-adjusting instructional video playback based on cognitive user activity detection analysis
US10848712B1 (en) * 2019-12-12 2020-11-24 Amazon Technologies, Inc. User-defined media source synchronization
CN109963184B (zh) * 2017-12-14 2022-04-29 阿里巴巴集团控股有限公司 一种音视频网络播放的方法、装置以及电子设备
US11557121B2 (en) * 2020-04-26 2023-01-17 Cloudinary Ltd. System, device, and method for generating and utilizing content-aware metadata

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103310669A (zh) * 2013-06-09 2013-09-18 深圳市拓莱思科技有限公司 一种用于互动教学的数据传输方法及系统
CN106790576A (zh) * 2016-12-27 2017-05-31 深圳市汇龙建通实业有限公司 一种互动桌面同步方法

Also Published As

Publication number Publication date
CN114257858A (zh) 2022-03-29

Similar Documents

Publication Publication Date Title
CN104969560B (zh) 一种检索媒体数据的方法和设备以及存储介质
US7133362B2 (en) Intelligent buffering process for network conference video
CN113037440B (zh) 数据重传处理方法、装置、计算机设备和存储介质
CN106341738B (zh) 流媒体网络传输的带宽计算方法、服务器端和系统
EP2088731A1 (en) Network communication data processing method, network communication system and client end
US20170041238A1 (en) Data flow control method
JPH09191314A (ja) 連続データ伝送方法および連続データ伝送装置
CN104284135B (zh) 视频传输方法及设备
CN108347625B (zh) 一种ts流媒体定位的方法和装置
US9813475B1 (en) Delivering a video stream
US20170353747A1 (en) Quality of Media Synchronization
CN109194974B (zh) 用于网络视频直播的媒体低延迟通信方法与系统
US20160134672A1 (en) Delivering partially received segments of streamed media data
CN109257610B (zh) 用于互联网远程教育的媒体低延时通信方法及系统
CN111541859A (zh) 视频会议处理方法、装置、电子设备及存储介质
Montagud et al. Enhanced adaptive RTCP-based Inter-Destination Multimedia Synchronization approach for distributed applications
CN114257858B (zh) 一种基于情感计算的内容同步方法和装置
CN115037416A (zh) 数据前向纠错处理方法、装置、电子设备和存储介质
Dalal et al. A new architecture for measuring and assessing streaming media quality
CN112383791A (zh) 一种媒体数据处理方法、装置、电子设备和存储介质
EP1940110A1 (en) Stream recording method, apparatus and system
CN116318545A (zh) 视频数据传输方法、装置、设备及存储介质
JP2004186793A (ja) ストリーミング配信装置、ストリーミング端末装置、ストリーミング配信システム、及びストリーミング配信方法
WO2023206359A1 (zh) 直播过程中虚拟形象的视觉行为和音频的传输播放方法和交互系统
Lucas et al. Distributed Error Recovery for Continuous Media Data in Wide-Area Multicast

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