首页> 中国专利> 基于IP机顶盒的MPEG1文件实时播放的方法

基于IP机顶盒的MPEG1文件实时播放的方法

摘要

本发明所述基于IP机顶盒的MPEG1文件实时播放的方法,针对现有单输入接口解码芯片将经过RTSP,RTP/RTCP传输协议分离的音、视频数据,合成类似MPEG1系统格式的数据流文件,从而实现在单输入接口IP机顶盒中进行MPEG1流媒体文件的下载和实时播放。所述基于IP机顶盒的MPEG1文件实时播放的方法,是针对RTP数据文件的封装过程而采取一种与之相反的过程,即在解码器上实现由RTP包还原成MPEG流。

著录项

  • 公开/公告号CN1972443A

    专利类型发明专利

  • 公开/公告日2007-05-30

    原文格式PDF

  • 申请/专利权人 海信集团有限公司;

    申请/专利号CN200510045440.X

  • 申请日2005-11-27

  • 分类号H04N7/26(20060101);H04N5/00(20060101);H04L29/06(20060101);

  • 代理机构37101 青岛联智专利商标事务所有限公司;

  • 代理人陈磊

  • 地址 266071 山东省青岛市市南区江西路11号

  • 入库时间 2023-12-17 18:37:50

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2009-02-25

    授权

    授权

  • 2007-07-25

    实质审查的生效

    实质审查的生效

  • 2007-05-30

    公开

    公开

说明书

技术领域

本发明是一种实现单输入接口IP机顶盒中的MPEG1流媒体文件进行下载并实时播放的方法。

背景技术

目前由于网络带宽、硬件本身处理能力和协议规范等方面的限制,从网络媒体下载大量的音、视频多媒体数据,对下载时间和存储空间都有很高的要求。对于存储空间比较小,对实时性要求比较高的单输入接口IP机顶盒来说,这一矛盾就显得尤为突出。

现有采用的流媒体技术很好地解决了这一难题。流是近年在网络上出现的新概念,主要是指通过网络传输多媒体数据的技术总称。

流媒体则包含广义和狭义两种内涵:广义上的流媒体,指的是使音频和视频形成稳定和连续的传输流和回放流的一系列技术、方法和协议的总称,即流媒体技术;狭义上的流媒体,是相对于传统的下载-回放方式而言的,指的是一种从网络上获取音频和视频等多媒体数据的新方法,其能够支持多媒体数据流的实时传输和实时播放。通过流媒体技术,服务器能够向客户端发送稳定和连续的多媒体数据流,客户端在接收数据的同时以一个稳定的速率回放,而不用等数据全部下载完之后再进行回放,即实现一种实时播放的模式。

目前流媒体传输主要采用的是RTSP,RTP/RTCP协议。RTP协议在传输时将音、视频数据进行分开传输,这样客户端接收到的数据包括独立的音、视频文件,因此一般的软件播放器采用音、视频分别接收和解码的方法,如附图3所示。而且,现有专门用于支持播放流媒体的硬件解码芯片较少,一般硬件解码芯片只支持单接口的本地文件播放,因此这类解码器是无法针对RTP协议传输数据进行解码和实时播放的。

发明内容

本发明所述基于IP机顶盒的MPEG1文件实时播放的方法,其目的在于解决上述问题而针对现有单输入接口解码芯片,将经过RTSP,RTP/RTCP传输协议分离的音、视频数据合成类似MPEG1系统格式的数据流文件,从而实现在单输入接口IP机顶盒中进行MPEG1流媒体文件的下载和实时播放。

所述基于IP机顶盒的MPEG1文件实时播放的方法,是针对RTP数据文件的封装过程而采取一种与之相反的过程,即在解码器上实现由RTP包还原成MPEG流。

根据RFC3550和RFC2250,流媒体服务器端MPEG流封装成RTP协议包时,一个视频RTP包,是由RTP固定包头、MPEG视频特定标头(可能有扩展头)、RTP有效载荷三部分构成的。一个音频RTP包,是由RTP固定包头、MPEG音频特定标头、RTP有效载荷三部分构成的。

上述过程实际上是对MPEG-1进行系统层解析的过程,即从MPEG流中搜索一些重要的信息填充到RTP包中几个重要的数据结构中,同时根据已有的规范来完成一个RTP包的封装。

而所述基于IP机顶盒的MPEG1文件实时播放的方法,是根据RTP包中的重要数据完成解码器进行实时播放,而实现MPEG1流媒体的PACK和PACKET头部数据填充,并按RTP序列号缓存重组得到的基本数据流,形成完整的MPEG1数据格式后,送入解码器进行解码、播放。

经过RTP传输后得到的分离媒体数据与本地文件的复用数据相比,一方面缺少了原来整个MPEG1文件的头部信息;另一方面,MPEG1文件中的PACK头部信息也没有传输,只是将某些字段映射到RTP头部。

所述基于IP机顶盒的MPEG1文件实时播放的方法,根据RTSP流传输中一些控制信息获得文件解码信息,用来初始化硬件解码器;

通过RTSP协议获得文件的SDP(Session Description Protocol,即会话描述协议)中得到媒体的类型、编码格式和持续时间等信息参数。其中,SDP用于说明一个流媒体会话的基本属性,包括媒体类型和编码格式、所需要的传输带宽、播放的时间范围、所需Buffer信息等。

根据MPEG1标准文件格式填充每帧数据的PACK和PACKET头部,通过RTP包的包头得到编码格式和时间戳;

根据MPEG1文件标准(即ISO/IEC 11172标准)填充相应的文件头信息,形成完整的文件头部格式,并按RTP序列号缓存重组得到的基本数据流,并通过缓存送到硬件解码器。

如上述内容,从硬件解码器的角度来看,重新组成的MPEG1数据与本地播放的文件格式没有本质区别,从而可由现有的解码器对经过RTP传输后得到的分离媒体数据进行下载、重组和实时播放。

所述基于IP机顶盒的MPEG1文件实时播放的方法,其实现流程是:

第一步,通过RTSP协议传输的SDP信息解析出解码器实时播放需要的文件信息参数。

从SDP信息中可以获取的信息参数包括有,文件类型,持续时间,音频,视频的编码格式,采样频率,最大速率等,上述参数用来初始化硬件解码器。

第二步,从网络服务器接收包含流媒体数据的RTP包。

针对参考信息,首先根据RTP包中的负载类型,来区分是音频还是视频数据;

然后根据RTP包中包含的序列号,从RTP包中提取媒体数据并进行重组;重组后的音频、视频数据文件是按顺序排列好的基本流,但此时仍不是完整的、具有逻辑意义的PACK文件,因此直接送给解码器是无法解码和实时播放的。

第三步,将音频、视频数据的每一帧都附加一个PACK头部。

第四步,在音频、视频数据的每一个帧前再分别增加上一个PACKET头部,以表明其是音频帧、还是视频帧,并且根据SDP信息填充缓冲区字段。

根据RTP包头中的时间戳信息填充显示时间戳PTS字段,其它的PACKET头部的字段按照固定格式填入相应的位信息。

第五步,将修改后的数据缓存,通过与硬件解码器的交互送入解码器进行解码,并将带有完整的MPEG1系统文件头部格式的数据进行实时播放。

如上述方法步骤所示,在实现MPEG1流媒体数据PACK和PACKET头部填充的过程中,MPEG1流媒体数据中的PACK数据码、复用速率、系统目标解码器缓冲区数据均从SDP信息中获取得到。

MPEG1流媒体数据中的流类型和显示时间戳,直接从RTP头部映射获得。

如上述方法步骤所示,在音频或视频数据的每一帧前附加PACK头部时,复用速率由以下表达式得出:

其中,

音频速率和视频速率是由SDP信息中“a=AvgBitRate:integer”字段中得出;

PACKET长度为固定值,是由SDP信息中(a=AvgPacketSize:integer)字段中得到。

所述基于IP机顶盒的MPEG1文件实时播放的方法,其优点是:可基于现有播放本地文件的解码芯片实时播放流媒体文件,不仅降低了系统设计和硬件投入成本,而且在不增加计算量的情况下实现视频点播功能。

附图说明

图1是RTSP协议中的SDP描述;

图2是RTP头部格式示意图;

图3是现有RTP数据传输和解码流程示意图;

图4是MPEG1流媒体数据的PACK示意图;

图5是MPEG1流媒体数据的PACKET示意图;

图6是根据本发明所述方法实现MPEG1流媒体数据PACK和PACKET头部填充示意图;

图7是本发明所述解码芯片的实时播放流程图。

具体实施方式

实施例1,如附图所示,所述基于IP机顶盒的MPEG1文件实时播放的方法步骤如下:

第一步,通过RTSP协议传输的SDP信息解析出解码器实时播放需要的文件信息参数。

从SDP信息中可以获取的信息参数包括有,文件类型,持续时间,音频,视频的编码格式,采样频率,最大速率等,上述参数用来初始化硬件解码器。

如图1所示,SDP中的下列参数可以获得的播放支持信息有:

“m=(媒体名称和传输地址)”字段获得媒体类型和编码格式;

“a=*(0个或多个会话属性行)”字段的格式是a=<属性>:<值>,其中属性包括有,持续时间、采样频率、最大速率、视频的宽高,音频的通道个数等;

第二步,从网络服务器接收包含流媒体数据的RTP包。

如图2所示,在RTP包中包括有如下参考信息,

“Ver”为RTP协议版本号;

“P”用于标志该RTP包的末尾是否包含有附加信息;

“X”用于标志是否存在扩展头部;

“CC”用于标志在固定头部后存在多少个CSRC标记;

“M”是标志位;

“负载类型”标记RTP包中所携带信息的类型;

“SSRC”用于标识数据源;

“CSRC”标识贡献的数据源。

针对上述参考信息,首先根据RTP包中的负载类型,来区分是音频还是视频数据;然后根据RTP包中包含的序列号,从RTP包中提取媒体数据并进行重组;重组后的音频、视频数据文件是按顺序排列好的基本流。

第三步,将音频、视频数据的每一帧都附加一个PACK头部。

如图4所示,PACK头部的起始码设置为是00 00 01 BA;

接着填充4个固定位‘0010’;

随后的36bit是系统参考时钟,表示送入系统目标解码器的时间;除了中间穿插的标志位以外的各位均填充为0;这是因为我们采用人工送入的方式,解码的时间依赖于人工送入的时间,因此填充为0不会影响解码器正常解码;

然后是24位的复用速率,表明码流进入解码器的速率,复用速率由下述表达式推算得出:

其中,音频速率和视频速率是由SDP信息中“a=AvgBitRate:integer”字段中得出;

PACKET长度为固定值,是由SDP信息中(a=AvgPacketSize:integer)字段中得到。

第四步,在音频、视频数据的每一个帧前再分别增加上一个PACKET头部,以表明其是音频帧、还是视频帧,并且根据SDP信息填充缓冲区字段。

根据RTP包头中的时间戳信息填充显示时间戳PTS字段,其它的PACKET头部的字段按照固定格式填入相应的位信息。

具体地,如图5所示,

PACKET头部的起始码前缀是00 00 01;

接下来的8个bit是stream_id,表示流的类型;若为音频帧则填充为C0;若为视频帧则填充为E0;

接着16位是包的长度packet_length,通过计算包头长度加数据长度获得;

然后填充2个固定位‘01’,以表明后面跟着的是系统目标解码器缓冲区缩放因子STD_buffer_scale(1个bit)和系统目标解码器缓冲区的大小STD_buffer_size(13个bit);

对于STD_buffer_scale字段,若为音频帧,则填充为0;若为视频帧,则填充为1;对于STD_buffer_size字段,其表示解码器缓冲区的大小,填充时首先判断视频的宽(a=Width:integer)和高(a=Height:integer)的大小(由SDP中获得);

如果遵从ISO/IEC 11172-2中定义的视频约束参数,则整个16位(2比特固定位‘01’+1比特STD_buffer_scale+13比特STD_buffer_size)音频填充为40 20,视频填充为60 2E。这是因为ISO/IEC 11172-1中规定对于遵从上述约束的流,使用最大缓冲区的大小为:视频流64×1024字节,音频流32×128字节,而音频缓冲区以128字节为单位,视频缓冲区以1024字节为单位,则(64)10=(2E)16,(32)10=(20)16;

如果不满足此约定,则视频缓冲区大小则从[64×1024]、以及中取较大的一个,其中,Rvmax是最大视频速率,其从SDP信息的“a=MaxBitRate:integer”字段中获得;

音频缓冲区,最大取32×128字节;在MPEG1文件以正常速率解码的情况下,上述设置的缓冲区不会产生溢出;

接下来填充4个固定bit‘0010’,表明其后面是显示时间戳PTS;在此过程中将RTP包头中的时间戳映射成PTS,因为时间戳反映了RTP packet所携带信息包中第一个字节的采样时间。

第五步,将修改后的数据缓存,通过与硬件解码器的交互送入解码器进行解码,并将带有完整的MPEG1系统文件头部格式的数据进行实时播放。

如图6和上述方法步骤所示,在实现MPEG1流媒体数据PACK和PACKET头部填充的过程中,

MPEG1流媒体数据中的PACK数据码、复用速率、系统目标解码器缓冲区数据均从SDP信息中获取得到。

MPEG1流媒体数据中的流类型和显示时间戳,直接从RTP头部映射获得。

如图7所示,应用支持单接口、本地文件播放的解码器,如本发明所述的MPEG1文件实时播放的方法,

首先,进行硬件初始化;

然后,通过RTSP协议获取SDP信息并分析解码器需要的支持播放信息;

随后,解码器通过交互判断是否可以解码;若可以解码,则利用RTP/RTCP协议接收数据,在实现MPEG1流媒体数据PACK和PACKET头部填充后,根据标志位向解码器中交互送入音、视频数据,以进行解码和实时播放的;

上述过程直至完成全部数据被解码和播放。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号