CN101060418B - 适用于带时移iptv直播服务器的专用磁盘读写系统 - Google Patents

适用于带时移iptv直播服务器的专用磁盘读写系统 Download PDF

Info

Publication number
CN101060418B
CN101060418B CN2007100411672A CN200710041167A CN101060418B CN 101060418 B CN101060418 B CN 101060418B CN 2007100411672 A CN2007100411672 A CN 2007100411672A CN 200710041167 A CN200710041167 A CN 200710041167A CN 101060418 B CN101060418 B CN 101060418B
Authority
CN
China
Prior art keywords
data
module
file
read
write
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.)
Expired - Fee Related
Application number
CN2007100411672A
Other languages
English (en)
Other versions
CN101060418A (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.)
SHANGHAI CLEARCRANE DIGITAL TECHNOLOGY Co Ltd
Original Assignee
SHANGHAI CLEARCRANE DIGITAL 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 SHANGHAI CLEARCRANE DIGITAL TECHNOLOGY Co Ltd filed Critical SHANGHAI CLEARCRANE DIGITAL TECHNOLOGY Co Ltd
Priority to CN2007100411672A priority Critical patent/CN101060418B/zh
Publication of CN101060418A publication Critical patent/CN101060418A/zh
Application granted granted Critical
Publication of CN101060418B publication Critical patent/CN101060418B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

本发明属于网络多媒体技术领域,具体涉及一个适用于带时移IPTV直播服务器的专用磁盘读写系统,以及使用该读写系统的带时移IPTV直播服务器。其中磁盘读写系统包括媒体数据缓存服务器和若干缓存客户端。缓存客户端分为直播数据写客户端和直接数据读客户端;媒体数据缓存服务器包括:频道管理模块、缓存管理模块和文件读写模块。缓存管理模块采用基于tmpfs和内存文件映射的内存,文件读写模块采用DIRECT I/O和异步I/O技术。使用所述读写系统的带时移IPTV直播服务器还包括媒体数据预处理模块、发送模块和用户管理模块,媒体数据从预处理模块经专用磁盘读写系统传输给发送模块,并最终发送到各个客户端播放器,从而提高带时移直播服务器的整体性能。

Description

适用于带时移IPTV直播服务器的专用磁盘读写系统
技术领域
本发明属于网络多媒体技术领域。具体涉及一个适用于带时移IPTV直播服务器的专用磁盘读写系统以及使用该专用磁盘读写系统的带时移IPTV直播服务器。
背景技术
IPTV(Internet Protocol Television)(网络电视)利用宽带网络、多媒体、通讯等技术,向机顶盒、PC、手机等用户终端提供数字电视等多种交互式服务。典型的IPTV应用包括视频直播和视频点播等。在IPTV视频直播应用中,时移(timeshift)是一个非常新颖的功能点。使用带时移直播服务,用户不仅可以观看当前时刻的直播内容,也可以对前面一段时间的内容进行实时类VCR(Video Cassette Recorder)操作,其中包含暂定、拖动、快进、快退等操作。本发明将提供时移服务的直播服务器称为带时移直播服务器。带时移直播服务器必须对直播数据进行持续、有效的存储,并按照用户的要求从存储中提取数据进行发送,所以磁盘读写策略与性能是其中的一个关键点。
与一般应用的磁盘读写等特性相比,带时移直播服务具有实时性、持续高流量数据I/O、用户行为连续等特点。目前通用型的Linux操作系统并不是针对这些特点进行设计的,在这类应用环境下难以达到好的性能。
发明内容
本发明的目的在于提供一种适用于带时移IPTV直播服务器的专用磁盘读写系统。以便有效提高磁盘读写效率,从而提升服务器的整体性能。
Linux系统默认的磁盘读写机制不能很好适应带时移直播服务器的磁盘读写的需要,本发明在使用了异步I/O、DIRECT I/O、tmpfs内存文件系统、共享内存等技术为基础,构建了一套适用于带时移IPTV直播服务器的专用磁盘读写系统,简称直播时移专用磁盘读写系统。
本发明将带时移IPTV直播服务器称为ClearLiveServer。ClearLiveServer中采用本发明的专用磁盘读写系统以提高其整体性能。图1是ClearLiveServer的整体架构示意图,图2是采用操作系统默认磁盘读写机制的普通带时移直播服务器的整体架构示意图。
ClearLiveServer架构
在详细说明专用磁盘读写系统的功能、结构之前,先对ClearLiveServer系统进行介绍。ClearLiveServer在总体上有四个组成部分:
1、媒体数据预处理模块
该模块用于对从原始直播数据源接收到的数据进行处理,转换成为适合直播时移应用的格式,并通过专用磁盘读写系统进行数据存储。同时维护频道的索引信息,在直播时移专用磁盘读写系统中需要用这个索引信息来进行数据的定位。
2、媒体数据发送模块
该模块把直播时移的节目,通过流媒体的形式发送到各个客户端。频道媒体数据通过专用磁盘读写系统获得。
因此,该模块接收用户管理模块布置的客户端传输任务,从专用磁盘读写系统获取频道媒体数据。
3、用户管理模块
该模块负责对用户进行管理,当有新的直播时移用户加入时,把数据传输的任务交给媒体数据发送模块。
因此,该模块向媒体数据发送模块布置客户端传输任务。
4、直播时移专用磁盘读写系统
该系统主要的功能有两点:①提供与文件系统类似的功能,但与一般的文件系统面向文件操作不同,直播时移专用磁盘读写系统是面向频道的,上层模块可以通过它来方便地写入或者读出频道的媒体数据;②在直播时移专用磁盘读写系统中根据直播时移数据存储和读取的特点,综合运用各种技术进行性能优化,能较充分地利用服务器的磁盘I/O系统和内存系统,来提升整个流媒体服务器的能力。
该系统从媒体数据预处理模块取得数据,并把数据提供给媒体数据发送模块。
由上可见,直播时移专用磁盘读写系统起到了一个关键的数据中转的作用,媒体数据从预处理模块传到直播时移专用磁盘读写系统,再从专用磁盘读写系统传给数据发送模块,并最终发送到各个客户端播放器。
直播时移专用磁盘读写系统架构
本发明提出的专用磁盘读写系统,采用C/S(客户端服务器)架构,它包含一个媒体数据缓存服务器和若干个缓存客户端。
缓存客户端包括两类:直播数据写客户端和直播数据读客户端。
1、直播数据写客户端
是专用磁盘读写系统中提供给外部模块进行频道数据写入操作的接口模块,通过它来创建一个频道,并向频道中写入数据。
该接口模块连接于媒体数据预处理模块和媒体数据缓存服务器模块之间。
2、直播数据读客户端
是专用磁盘读写系统中提供给外部模块进行频道数据读取操作的接口模块,通过它来打开已有的频道,并从频道中获取数据,以提供给媒体数据发送模块进行数据发送。该接口模块连接于媒体数据发送模块和媒体数据缓存服务器模块之间。
媒体数据缓存服务器分为三个子模块:频道管理模块、缓存管理模块和文件读写模块。
1、频道管理模块
在系统中,单个频道的数据由若干个数据文件组成,同时还有每个数据文件对应的索引文件,以及可对这些索引文件进行检索的频道索引。频道管理模块的作用是接收客户端的请求,通过一系列的索引,把用户请求的数据定位到具体的数据文件中,再通过调用缓存管理模块提供的接口,进行数据块的处理。
模块间关系:接收缓存客户端的请求,调用缓存管理模块的接口来获取或者写入数据块。频道索引由媒体数据预处理模块进行维护。
2、缓存管理模块
系统中的媒体数据文件按照数据块的形式来组织,对媒体数据文件的读取和写入也都是以数据块为单位进行,块状数据处理可以尽量减小I/O操作。缓存块是在系统内存中分配,每个缓存块都可以存放一个数据块。
缓存块管理模块的作用是维护所有的缓存块,为媒体数据文件中的数据块分配缓存块,被分配到缓存块的数据块,在以后的访问中,可以直接使用在内存中的数据,不需要访问硬盘。由于物理内存容量有限,媒体文件中的数据块只有一部分可以被分配到,当需要存放新的数据块时,缓存块管理模块会在当前的缓存池中选出最不可能被使用到的数据块,把它占有的缓冲块释放出来,用于存放新的数据块。
模块间关系:频道管理模块通过调用缓存管理模块的接口,来向媒体数据文件中写入数据块或从媒体数据文件中读取数据块;缓存管理模块会向文件读写模块发起数据块的读写请求,由文件读写模块把文件中的数据块读取并放到缓存块中,或者把缓存块中的数据写入到实际的文件中。
采用的技术:
使用基于tmpfs和内存文件映射的内存:在缓存块管理模块中,缓存块不像一般的程序通过malloc等类似调用来获得,而是通过Linux系统中的tmpfs文件系统以及内存文件映射机制来实现。在考虑下面几点要求的前提下,结合tmpfs文件系统和内存文件映射来表示缓存块:
①缓存块管理需要大量的内存,来达到较高的缓冲命中率。
②缓存块需要可以高效地在不同模块之间共享。
③在通常的32位系统上,进程的可用地址空间是2GB,而商用服务器的内存可以超过这个数目,需要有效使用系统的内存。
tmpfs是基于系统内存的文件系统,也就是说在tmpfs下的文件实际上都存放在系统内存中。而且tmpfs可以充分利用服务器的内存资源,不会有2GB的限制。再加上内存文件映射技术,可使得:1,在不同的模块间,通过对在tmpfs中的同一个文件的映射,就可以实现数据的共享;2内存文件映射是动态的,可以随时建立和撤销,既可以使用到巨大的系统内存,又不会造成进程的地址空间不足。
ii、缓存管理:缓存管理主要是为有价值(被多次使用的可能性大)的数据块分配缓存块,从另一个方面也就是要把缓存块从最没价值(对多次使用的可能性小)的数据块中释放出来。在为新的数据块分配缓存块时,如果缓存块不足,就需要用数据块淘汰算法选择出一块最不可能会被使用到的数据块,把它占用的缓存块释放出来,用来存放新的数据块。淘汰算法要选择最晚被用到的数据块。用流来表示某个用户观看直播时移时候的状态,主要关注当前使用的数据块在媒体文件中所处的位置。在正常播放状态下,媒体流获取数据的顺序是依次往后,数据块的下次访问时间可以用它与前面邻近的流之间的距离来表示,距离越远就越晚会被用到。为了较快地找出最晚被使用到的数据块,先找出单个媒体文件中最晚访问的数据块,再从所有这样的数据块中选出最终的最晚访问的数据块。同时注意到夹在两个流之间的数据块,最靠后面的数据块必然比前面的要晚访问,所以只要比较每个相邻流之间最靠后的数据块就可以了。
3、文件读写模块
文件读写模块的作用是接收上层发起的数据块读写请求,把数据块从文件中读出,放到缓存块中,或者把数据块的内容从缓存块中写入到文件。
模块间关系:被缓存管理模块调用,进行实际的媒体数据文件的数据块读写。与缓存管理模块在不同的线程中运行。
采用的技术:在文件读写模块中,采用两个技术:DIRECT I/O和异步I/O。
i、DIRECT方式的磁盘I/O绕过了系统的文件系统缓存,把文件读写请求直接交给磁盘,这可以避免在使用Linux下默认的文件系统缓存机制时,对流媒体系统的服务质量造成的影响。在使用文件缓存时,Linux会尽量地使用内存作为缓存,来达到通用情况下较好的磁盘吞吐性能,但是这有两点地方会对流媒体系统的服务质量造成影响:1,只有当缓存中的脏数据较多时,才会发起大量写请求,把数据刷新到实际的磁盘文件中,这样的写操作带有很强的突发性,会在这段时间内占用大量的系统资源,从而对别的应用造成影响,特别是对流媒体服务这样时间敏感的应用,会使得短时间内数据处理能力不足,影响服务质量;2,流媒体应用中的磁盘读写规律有着其自身的特点,默认的文件系统缓存是针对一般的用途,因而不能达到最好的效果。通过DIRECT I/O,我们可以构造自己的适合流媒体应用的缓存机制,提高服务器的性能。
ii、异步I/O的主要特征就是操作请求的发起和操作结果的获得是分开的。主要优点有:数据处理和I/O操作重叠进行,有利于提高CPU的使用率;在同步IO中,只有一个请求完成了以后,才能进行下一次请求,磁盘的性能不能很好表现出来,而通过异步I/O可以使得磁盘设备的请求管道中总是保持一定量的请求,有利于提高其利用率。把异步I/O与DIRECT I/O的直接把读写请求发送给磁盘设备的特点相结合,我们通过控制发送请求的频率来控制磁盘的吞吐量,使磁盘系统对整个流媒体系统的影响保持在一个较低的水平。
处理流程
在介绍完直播时移专用磁盘读写系统的架构、组成后,我们再用动态的流程来描述系统运行时的状况。下面按照媒体数据的接收和发送两条线索分别进行描述。
当媒体数据被接收时,ClearLiveServer中的各个模块会进行下面这些流程的处理(如图3):
(1)媒体数据预处理模块:
a)从原始数据源接收直播数据;
b)把数据进行处理,如判断是否是关键帧,记录接收时间等;
c)把数据放到从媒体数据缓存服务器得到的缓冲块队列的队头缓冲块中(缓冲块用于存放最新接收的数据,队列中有若干个缓冲块);
d)如果队头缓冲块数据已经满了,通过直播数据写客户端向媒体数据缓存服务器写入最新的数据块,然后调整缓冲块队列-把队头缓冲块移到队尾(缓存块队列是循环使用的);
e)更新频道的索引。
(2)媒体数据缓存服务器模块:
a)最新的数据往往最可能被用户需要,所以频道管理模块从缓存管理模块中取得一块空闲的缓存块,把它分配给最新的数据块,并且直接把当前最新缓冲块(在媒体数据预处理模块和媒体数据缓存服务器模块之间共享)的内容复制到这个缓存块中;
b)为了把新数据块写到磁盘文件中,对文件读写模块发起写请求;
c)文件读写模块从写请求队列中获取一定数量的请求,并用异步的方式向操作系统递交写请求;
d)文件读写模块等待异步操作完成。
当媒体数据被发送到客户端时,ClearLiveServer中的各个模块会进行下面这些流程的处理(如图4):
(1)媒体数据发送模块:
a)当前流的数据块中的数据是否已经被发送完毕,如果是的话,通过直播数据读客户端向媒体数据媒体数据缓存服务器请求数据
b)把当前流数据块中的数据按照发送计划发送到客户端。
(2)媒体数据缓存服务器模块:
常规的数据获取流程:
a)频道管理模块根据频道索引,计算出请求的数据所在的媒体文件以及偏移位置,向缓存管理模块请求数据。
b)缓存管理模块检查对于的数据块是否在缓存中。如果不在缓存中,则通过数据块淘汰算法,得到一个空闲的缓存块,分配给请求的的数据块,并向文件读写模块发起读请求。
c)文件读写模块从读请求队列中获取一定数量的请求,并用异步的方式向操作系统递交读请求。
d)文件读写模块等待异步操作完成,并标记完成读取的缓存块的可用位,以表示缓存块中已经包含有效数据,可以被其他模块使用。
数据预读流程:
除了上面说明的对数据获取请求的处理外,为了进一步提高缓存的命中率,我们根据流媒体数据读取的特点,进行了数据预读的处理。处理流程和常规的数据获取流程基本一样,只在前面多了一步对预读数据块的预测。
a)判断下一个可能被读取的数据块(根据不同情况,可能是前面常规流程中请求数据块的下一块,也可能是上一块);
b)频道管理模块根据频道索引,计算出请求的数据块所在的媒体文件以及偏移位置,向缓存管理模块请求数据;
c)缓存管理模块检查对于的数据块是否在缓存中。如果不在缓存中,则通过数据块淘汰算法,得到一个空闲的缓存块,分配给请求的的数据块,并向文件读写模块发起读请求;
d)文件读写模块从读请求队列中获取一定数量的请求,并用异步的方式向操作系统递交读请求;
e)文件读写模块等待异步操作完成,并标记完成读取的缓存块的可用位,以表示缓存块中已经包含有效数据,可以被其他模块使用。
附图说明
图1是采用了专业磁盘读写系统的ClearLiveServer的整体架构示意图。
图2是采用操作系统默认磁盘读写机制的普通带时移直播服务器的整体架构示意图。
图3是媒体数据接收时系统主要流程图。
图4是媒体数据发送时系统主要流程图。
图中标号:1为用户管理模块,2为媒体数据预处理模块,3为媒体数据发送模块,4为直播数据写客户端,5为直播数据读客户端,6为频道管理模块,7为缓冲管理模块,8为文件读写模块,9为直播时移专用磁盘读写系统,10为媒体数据缓存服务器,11为存储介质,12为用户,13为操作系统默认I/O模块。
具体实施方式
下面对本发明的具体实施和进一步描述。
基本数据结构
在Linux系统下,默认的tmpfs内存文件系统被挂载在/dev/shm下,因此系统中的缓存块也存放在/dev/shm下。直播时移专用磁盘读写系统初始化时,会在/dev/shm下面创建一系列文件,文件的大小都一致,每一个文件都代表了一个缓存块。缓存块在系统中用结构体CachedBlock来表示:
struct CachedBlock{
  char block_data[CACHED_BLOCK_SIZE];
  int state;
}
缓存块包括了数据块block_data和标志位state,在用于读取数据块时,标记位state用DATA_READY和DATA_NREADY来分别表示block_data中是否已经包含有效数据。
为了方便管理我们还使用了一个控制块的结构,用来描述缓存块和/dev/shm下内存文件的关系:
struct ManagedBlock{
    char block_file[PATH_MAX];
    int fd;
    CachedBlock*cached_block;
}
其中block_file表示了在/dev/shm中的内存文件的文件名,fd是这个文件的描述符,cached_block是通过文件内存映射过来的缓存块,由于进程的虚存空间有限,只有在需要的时候才进行缓存块的映射。映射的方法为:managed_block->cached_block=(CachedBlock*)mmap(NULL,sizeof(CachedBlock),PROT_READ|PROT_WRITE,MAP_SHARED,managed_block->fd,0);解除映射的方法为munmap(managed_block->cached_block,sizeof(CachedBlock))。通过在不同模块间对相同的内存文件进行映射,就可实现进程间缓存块的共享。
直播数据读客户端
直播数据读客户端用ChannelReadFile来表示,在媒体数据发送模块每个播放的流都拥有一个ChannelReadFile,通过ChannelReadFile从媒体数据媒体数据缓存服务器获取数据。
ChannelReadFile有如下的一些方法:
bool open(char*channel);//打开频道
bool close();//关闭频道
CachedBlock*getBlockByTime(uint64time);//取得某个时间点的数据
CachedBlock*getPreBlock();//取得上一块数据
CachedBlock*getNextBlock();//取得下一块数据
CachedBlock*getOldestBlock();//取得最老的数据
ChannelReadFile和媒体数据缓存服务器之间通过Unix Domain Socket进行通信,UnixDomain Socket类似与一般的网络套接字,但它专门用于进程间通信,效率很高。ChannelReadFile向媒体数据媒体数据缓存服务器模块发送请求,根据请求的结果来完成具体的功能,其中后面四个取数据块的操作都是从缓冲服务器得到包含所请求的数据的缓存块的文件名,并把这个内存文件映射到进程地址空间中。
通过ChannelReadFile来获取数据是先得到一个CacheBlock结构,再通过监测其中的标记位来判断数据块是否可用,这使得当某些流的数据还没准备好的时候,还可以进行别的数据流的数据发送工作,而不至于一直等待某个流的数据到达,而耽误别的流的发送,这样就提高了系统的服务质量,不同流之间的互相干扰尽量减小。
直播数据写客户端
直播数据写客户端用ChannelWriteFile来表示,每个频道都有一个ChannlWriteFile,通过ChannelWriteFile向媒体数据缓存服务器写入媒体数据。ChannelWiteFile与媒体数据缓存服务器之间也是使用Unix Domain Socket进行通信。
ChannelWriteFile有如下一些方法:
ChannelIndex*open(char*channel_name);//创建一个频道
CachedBlock**getBuffer(int size);//获得一组缓存数据块
bool close();//关闭一个频道
bool putBlock();//把最新数据块的内容写到磁盘上
用open方法成功创建一个频道后,会得到一个与媒体数据缓存模块之间共享的频道索引结构,这个频道的索引由媒体数据预处理模块进行维护,而媒体数据缓存服务器利用它来进行数据块的查找。
由于时移节目存储的媒体数据很庞大,单个文件无法容纳,在系统中一个频道由一组媒体数据文件来表示,此外为了管理这些数据文件,还引入了索引,索引分为两层,每个媒体文件有自己的索引,又有一个关于这一级索引的频道总索引。索引信息由媒体数据接收模块维护。
每个媒体文件索引为
struct ChannelSegmentIndex{
          int block_count;//块的数量
          uint64start_time;//文件中最旧数据的时间
          uint64end_time;//文件中最新数据的时间
          ChannelBlockIndex blocks[BLOCK_COUNT_MAX];//数据块的索引
}
其中每个数据块的索引为:
struct ChannelBlockIndex{
          uint64   start_time;//数据块中最旧数据的时间
          uint64   end_time;//数据块中最新数据的时间
}
每个频道的总索引为:
struct ChannelIndex{
          uint64   start_time;//频道中最旧数据的时间
          uint64   end_time;//频道中最新数据的时间
          int first_segment_offset;//第一个媒体文件索引在下面数组中的偏移量
          int segment_count;//媒体文件的个数
          ChannelSegmentSimpleIndex segments[SEGMENT_COUNT_MAX];//缩略的媒
体文件索引
}
ChannelSegmentSimpleIndex表示了媒体文件的一些简单信息:
struct ChannelSegmentSimpleIndex{
          char index_file[PATH_MAX];//媒体索引文件名
          char data_file[PATH_MAX];//媒体数据文件名
          uint64start_time;//文件中最旧数据的时间
          uint64end_time;//文件中最旧数据的时间
          int block_count;//文件中的数据块数目
}
利用上面的这些索引信息,可以对某个时间点的数据进行定位,也可以对相对位置进行定位,如当前位置的后一块数据或前一块数据等。
需要接收数据时,用getBuffer方法来获得一批存放媒体数据的缓冲区数据块,当最新的缓冲区数据块被填满后,使用putBlock方法向媒体数据缓存模块申请把数据写入到磁盘上,然后把最老的缓冲区数据块作为数据接收使用的数据块,也就是说依次循环使用这批缓冲区数据块。在把数据填充到数据块中后,还需要陆续修改频道索引结构中的各个字段,使数据内容和索引结构保持一致,修改的选择是从小到大、从下到上,即按ChannelBlockIndex、ChannelSegmentIndex、ChannelSegmentSimpleIndex、ChannelIndex的次序进行了修改。由于在媒体数据缓存服务器中,对索引的查找是按从大到小、从上到下的次序,即ChannelIndex、ChannelSegmentSimpleIndex、ChannelSegmentIndex、ChannelBlockIndex,上面修改次序可以保证上层的索引总是反映了下层的实际情况,从而使得检索正确进行。
媒体数据媒体数据缓存服务器
媒体数据媒体数据缓存服务器是专用磁盘读写系统的核心,管理所有的缓存块,处理来自媒体数据接收模块和媒体数据发送模块的各种请求。
频道管理模块和缓存管理模块
在媒体数据媒体数据缓存服务器中,每个媒体文件都用结构体Movie来表示:
struct Movie{
   char_file_name[PATH_MAX];
   int fd;
   ManagedBlock*blocks[BLOCK_MAX];
   int block_count;
   Stream*first_stream;
   Stream*last_stream;
}
file_name表示了媒体文件的路径,fd是对应的文件描述符,blocks是对文件中数据块的简单索引,如果数据块被分配了缓存块,则在blocks数组中对应的管理块就非空,block_count表示媒体文件中包含的数据块的数量,first_stream和last_stream分别表示了当前的数据请求位置在这个媒体数据文件中的第一个数据流和最后一个数据流。打开媒体文件的时候,我们使用了movie->fd=open(movie->file_name,O_RDWR|O_LARGEFILE|O_DIRECT)的方式,其中O_LARGEFILE表示支持超过4G的大文件(因为媒体文件可能很大),O_DIRECT表示对此文件的操作最大程度上绕过系统的缓存机制,这使得我们在上层构建特殊的缓存机制成为可能。
我们用结构体stream来表示流:
struct Stream{
     int block_id;
     Stream*pre_stream;
     Stream*next_stream;
}
block_id表示了流在媒体数据文件中所处位置,pre_stream指向相邻的位置靠前的流,而next_stream指向相邻的位置靠后的流。
通过Movie结构体中的信息,可以得出当前缓存块的分配情况,从而应用前面提到的数据块淘汰算法释放缓存块,来把这个缓存块分配给更有价值的数据块。
媒体数据缓存服务器在接受到频道数据读客户端的数据请求时,除了根据客户端实际的数据请求提供数据外,还需要根据客户端的行为预测它后面可能会读取的数据。数据预读处理中的预测如下:
1.如果是getBlockByTime、getOldestBlock或者getNextBlock请求,需要预取当前所需的数据块的后一个邻近数据块。
2.如果是getPreBlock请求,需要预取当前所需的数据块的前一个邻近数据块。
文件读写模块
文件读写模块实际上可以分成文件读模块和文件写模块,并且运行在两个单独的线程中。
文件读模块:
文件读模块对外提供的接口用来添加一个异步读的请求:addReadRequest(int file_fd,intblock_id,CachedBlock*store)。在模块内部维护了一个读请求的队列,在需要时才对请求进行处理。file_fd表示需要读取的文件的描述符,block_id表示从0开始的数据块序号,store表示需要读取后的数据存放的缓存块。CachedBlock中的block_data表示了实际数据存放的地方,而state是个标记位,用来表示数据是否已经被放入了block_data缓冲区,分别用DATA_READY,DATA_NREADY来表示数据已经读入和数据未被读入。
在Linux的异步I/O操作中,需要用到下面一些结构:
结构体aio_context_t是Linux系统异步I/O中异步操作的上下文,结构体struct iocb表示异步操作的请求块。
前面已经描述过了对于读请求的处理流程(图4),下面进一步用实际程序中的过程进行描述:
1、从读请求队列中获取一定量的请求,新获取请求的数目加上递交的但未完成请求的数目不能大于A_READ_MAX,这保证了不会对磁盘造成太大压力,有利于系统稳定,目前系统中A_READ_MAX为10。对每个新请求都进行下面两步操作:
a)借助io_prep_pread把addReadRequest中的异步读请求转换为系统需要的请求块形式,如io_prep_pread(io,file_fd,store,CACHED_BLOCK_SIZE,CACHED_BLOCK_SIZE*block_id),表示了把文件file_fd中偏移量为CACHED_BLOCK_SIZE*block_id字节处的CACHED_BLOCK_SIZE字节的数据读取到store指向的缓冲区中,而这个请求用io这个请求块来表示。
b)通过io_submit向操作系统递交异步I/O请求,如io_submit(io_context,1,&io)。
2、用io_getevents来等待异步操作的完成,当成功完成后,把对应的CachedBlock的state标记置成DATA_READY。
文件写模块:
异步模式文件写模块和读模块的处理流程类似(图3),除了准备异步请求块时用io_prep_pwrite,当异步操作完成时,不需要进行别的处理。

Claims (6)

1.一种适用于时移IPTV直播服务器的专用磁盘读写系统,其特征在于它包含一个媒体数据缓存服务器和若干个缓存客户端;其中,
缓存客户端包括直播数据写客户端和直播数据读客户端:
(1)直播数据写客户端
是专用磁盘读写系统中提供给外部模块进行频道数据写入操作的接口模块,通过它来创建一个频道,并向频道中写入数据;该接口模块连接于媒体数据预处理模块和媒体数据缓存服务器模块之间;
(2)直播数据读客户端
是专用磁盘读写系统中提供给外部模块进行频道数据读取操作的接口模块,通过它来打开已有的频道,并从频道中获取数据,以提供给媒体数据发送模块进行数据发送;该接口模块连接于媒体数据发送模块和媒体数据缓存服务器模块之间;
媒体数据缓存服务器分为三个子模块:频道管理模块、缓存管理模块和文件读写模块:
(1)频道管理模块
频道管理模块的作用是接收客户端的请求,通过一系列的索引,把用户请求的数据定位到具体的数据文件中,再通过调用缓存管理模块提供的接口,进行数据块的处理;
模块间关系:接收缓存客户端的请求,调用缓存管理模块的接口来获取或者写入数据块;频道索引由媒体数据预处理模块进行维护;
(2)缓存管理模块
系统中的媒体数据文件按照数据块的形式来组织,对媒体数据文件的读取和写入也都以数据块为单位进行,缓存块在系统内存中分配,每个缓存块都可以存放一个数据块;
缓存块管理模块的作用是维护所有的缓存块,为媒体数据文件中的数据块分配缓存块,被分配到缓存块的数据块,在以后的访问中,可以直接使用在内存中的数据;
模块间关系:频道管理模块通过调用缓存管理模块的接口,来向媒体数据文件中写入数据块或从媒体数据文件中读取数据块;缓存管理模块会向文件读写模块发起数据块的读写请求,由文件读写模块把文件中的数据块读取并放到缓存块中,或者把缓存块中的数据写入到实际的文件中;
(3)文件读写模块
文件读写模块的作用是接收上层发起的数据块读写请求,把数据块从文件中读出,放到缓存块中,或者把数据块的内容从缓存块中写入到文件;
模块间关系:被缓存管理模块调用,进行实际的媒体数据文件的数据块读写;与缓存管理模块在不同的线程中运行。
2.根据权利要求1所述的适用于时移IPTV直播服务器的专用磁盘读写系统,其特征在于所述缓存管理模块使用基于tmpfs和内存文件映射的内存;缓存管理模块在为新的数据块分配缓存时,如果缓存块不足,则通过一数据块淘汰算法,选择出一块最不可能被使用的数据块,把它占用的缓存块释放出来,用来存放新的数据块。
3.根据权利要求1所述的适用于时移IPTV直播服务器的专用磁盘读写系统,其特征在于所述的文件读写模块采用DIRECT I/O和异步I/O。
4.一种使用如权利要求1所述的专用磁盘读写系统的时移IPTV直播服务器,其特征在于该直播服务器还包括媒体数据预处理模块、媒体数据发送模块和用户管理模块,其中:
(1)媒体数据预处理模块
该模块用于对从原始直播数据源接收到的数据进行处理,转换成为适合直播时移应用的格式,并通过专用磁盘读写系统进行数据存储;同时维护频道的索引信息,在直播时移专用磁盘读写系统中需要用这个索引信息来进行数据的定位;
(2)媒体数据发送模块
该模块把直播时移的节目,通过流媒体的形式发送到各个客户端;频道媒体数据通过专用磁盘读写系统获得;
(3)用户管理模块
该模块负责对用户进行管理,当有新的直播时移用户加入时,把数据传输的任务交给媒体数据发送模块。
5.一种如权利要求4所述的时移IPTV直播服务器的处理流程,其特征在于具体步骤如下:
当媒体数据被接收时,IPTV直播服务器中的各个模块进行如下些流程的处理:
(1)媒体数据预处理模块:
a)从原始数据源接收直播数据;
b)把数据进行处理:如判断是否是关键帧,记录接收时间;
c)把数据放到从媒体数据缓存服务器得到的缓冲块队列的队头缓冲块中;
d)如果队头缓冲块数据已经满了,通过直播数据写客户端向媒体数据缓存服务器写入最新的数据块,然后调整缓冲块队列-把队头缓冲块移到队尾;
e)更新频道的索引;
(2)媒体数据缓存服务器模块:
a)频道管理模块从缓存管理模块中取得一块空闲的缓存块,把它分配给最新的数据块,并且直接把当前最新缓冲块的内容复制到这个缓存块中;
b)为了把新数据块写到磁盘文件中,对文件读写模块发起写请求;
c)文件读写模块从写请求队列中获取一定数量的请求,并用异步的方式向操作系统递交写请求;
d)文件读写模块等待异步操作完成;
当媒体数据被发送到客户端时,IPTV直播服务器中的各个模块会如下流程的处理:
(1)媒体数据发送模块:
a)当前流的数据块中的数据是否已经被发送完毕,如果是的话,通过直播数据读客户端向媒体数据媒体数据缓存服务器请求数据;
b)把当前流数据块中的数据按照发送计划发送到客户端;
(2)媒体数据缓存服务器模块:
常规的数据获取流程:
a)频道管理模块根据频道索引,计算出请求的数据所在的媒体文件以及偏移位置,向缓存管理模块请求数据,
b)缓存管理模块检查对于的数据块是否在缓存中,如果不在缓存中,则通过数据块淘汰算法,得到一个空闲的缓存块,分配给请求的的数据块,并向文件读写模块发起读请求;
c)文件读写模块从读请求队列中获取一定数量的请求,并用异步的方式向操作系统递交读请求;
d)文件读写模块等待异步操作完成,并标记完成读取的缓存块的可用位,以表示缓存块中已经包含有效数据,可以被其他模块使用。
6.根据权利要求5所述的时移IPTV直播服务器的处理流程,其特征在于在所述频道管理模块中,常规的数据获取流程步骤之前有一对预读数据块的预读流程:
a)判断下一个可能被读取的数据块;
b)频道管理模块根据频道索引,计算出请求的数据块所在的媒体文件以及偏移位置,向缓存管理模块请求数据;
c)缓存管理模块检查对于的数据块是否在缓存中,如果不在缓存中,则通过数据块淘汰算法,得到一个空闲的缓存块,分配给请求的的数据块,并向文件读写模块发起读请求;
d)文件读写模块从读请求队列中获取一定数量的请求,并用异步的方式向操作系统递交读请求;
e)文件读写模块等待异步操作完成,并标记完成读取的缓存块的可用位,以表示缓存块中已经包含有效数据,可以被其他模块使用。
CN2007100411672A 2007-05-24 2007-05-24 适用于带时移iptv直播服务器的专用磁盘读写系统 Expired - Fee Related CN101060418B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN2007100411672A CN101060418B (zh) 2007-05-24 2007-05-24 适用于带时移iptv直播服务器的专用磁盘读写系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN2007100411672A CN101060418B (zh) 2007-05-24 2007-05-24 适用于带时移iptv直播服务器的专用磁盘读写系统

Publications (2)

Publication Number Publication Date
CN101060418A CN101060418A (zh) 2007-10-24
CN101060418B true CN101060418B (zh) 2012-01-25

Family

ID=38866326

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2007100411672A Expired - Fee Related CN101060418B (zh) 2007-05-24 2007-05-24 适用于带时移iptv直播服务器的专用磁盘读写系统

Country Status (1)

Country Link
CN (1) CN101060418B (zh)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101557419B (zh) * 2009-05-06 2012-07-11 成都市华为赛门铁克科技有限公司 一种数据读写系统和数据管理方法
CN101692229B (zh) * 2009-07-28 2012-06-20 武汉大学 基于数据内容的三维空间数据自适应多级缓存系统
CN101883255A (zh) * 2010-06-17 2010-11-10 中兴通讯股份有限公司 一种交互式网络电视中点播节目的处理系统及其方法
CN102426553B (zh) * 2011-11-11 2014-05-28 中国科学技术大学 基于双缓存预读的向用户传输数据的方法和装置
CN102857730A (zh) * 2012-08-23 2013-01-02 苏州阔地网络科技有限公司 一种缓存帧数据的方法及系统
CN104063375A (zh) * 2013-03-18 2014-09-24 深圳市腾讯计算机系统有限公司 管道通讯的方法和装置
CN104598394A (zh) * 2013-10-31 2015-05-06 中国石油天然气集团公司 一种可动态分配的数据缓存方法及系统
CN104090939A (zh) * 2014-06-30 2014-10-08 国家电网公司 智能变电站海量数据存储及快速索引方法
CN105721388A (zh) * 2014-11-30 2016-06-29 中国科学院沈阳自动化研究所 不稳定网络环境下的mes客户端数据缓存方法及系统
CN104881248B (zh) * 2015-05-11 2018-04-17 中国人民解放军国防科学技术大学 面向ssd的文件系统中自适应直接io加速方法
CN105915985A (zh) * 2015-12-15 2016-08-31 乐视致新电子科技(天津)有限公司 一种直播中进行回看的方法及装置
CN107979570A (zh) * 2016-10-25 2018-05-01 北京优朋普乐科技有限公司 网络电台资源数据处理方法和装置
CN110046047A (zh) * 2019-04-15 2019-07-23 Oppo广东移动通信有限公司 一种进程间通信方法、装置及计算机可读存储介质
CN110109845B (zh) * 2019-04-26 2021-03-05 深圳忆联信息系统有限公司 缓存数据管理方法、装置、计算机设备及存储介质

Also Published As

Publication number Publication date
CN101060418A (zh) 2007-10-24

Similar Documents

Publication Publication Date Title
CN101060418B (zh) 适用于带时移iptv直播服务器的专用磁盘读写系统
CN106878315B (zh) 可变速率媒体传送系统
US6642966B1 (en) Subliminally embedded keys in video for synchronization
US7143433B1 (en) Video distribution system using dynamic segmenting of video data files
US8116609B2 (en) Method and apparatus for traversing a multiplexed data packet stream
US7246369B1 (en) Broadband video distribution system using segments
CN101636726B (zh) 包含连续播放的视频分配系统
US7039784B1 (en) Video distribution system using dynamic disk load balancing with variable sub-segmenting
US8411758B2 (en) Method and system for online remixing of digital multimedia
KR102274466B1 (ko) 실시간 캐싱 기법을 이용한 동영상 스트리밍 방법 및 그 시스템
US20110191447A1 (en) Content distribution system
CN101083756A (zh) 基于互联网的电视流媒体数据实时传输和服务装置及方法
US20070169158A1 (en) Method and system for creating and applying dynamic media specification creator and applicator
JP2001521342A (ja) デジタルビデオデータの同時のエンコードおよびタグ付けを行なうための方法および装置
JP2001521341A (ja) インプログレスビデオフィードへの非順次アクセスのための方法および装置
FI116167B (fi) Arkistoiva tiedostopalvelin
JP2003530745A (ja) 複数クライアントへの単一メディア・トラックのストリーミング
CN101193273A (zh) 一种实时多媒体图像信息存储和播放方法
US20090103835A1 (en) Method and system for combining edit information with media content
CN101477575A (zh) 一种多媒体信息存储和播放方法及其装置
CN108881942A (zh) 一种基于分布式对象存储的超融合常态录播系统
CN100418071C (zh) 一种媒体文件系统的建立方法
CN101312522A (zh) 视频点播系统
CN102158344B (zh) 并行组播网络文件系统
US7924456B1 (en) Data distribution and buffering

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
C17 Cessation of patent right
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20120125

Termination date: 20140524