JMF介绍之基于时间的媒体

简介:
1.         基于时间的媒体(time-based media
任何数据随时间的变化而变化的可被定义为基于时间的媒体。音频剪辑,MIDI序列,视频剪辑,动画都是基于时间的媒体形式。
下图从基本的数据处理过程模式角度说明了基于时间的媒体的主要特点和使用过程:
 
2.         流媒体(streaming media
基于时间的媒体的一个主要特点是它必须被实时的传输和处理。一旦这个媒体数据流打开,它的接收(receiving)和显示(presenting)数据必须要基于时间。正因为此,基于时间的媒体通常被定义为流媒体(streaming media)。
 
2.1内容类型(content type
媒体存储的格式称为它的内容类型(content type)。QuickTime, MPEG, WAV 都是内容类型的一种。
 
2.2媒体流(media streams
媒体流是指从本地文件,网络或相机,麦克中得到的媒体数据。媒体流通常包含多个数据通道,称其为道(tracks)。例如,一个Quicktime文件可能包含一个音频道和一个视频道。包含多道的媒体流通常被称为复合的(multiplexed)或合成的(complex)媒体流。分离(Demultiplexing)是指从一个合成的媒体流中提取单个道的过程。
一个道的类型(type)识别了它所包含的数据的类型,比如是音频的或视频的。一个道的格式(format)定义了它所包含的数据结构。
一个媒体流可以通过它的存储位置和用于访问它的协议来识别。例如,可以使用URL来定位一个本地的或非本地的QuickTime文件。如果它是本地的,可以通过文件协议(FILE protocol)访问它。如果它在一个Web服务器上,可以通过HTTP协议(HTTP protocol)访问它。当无法使用URL来定位媒体流时,可以使用一个媒体定位器(media locator)来识别媒体流的位置。
以下是基于传输方式的媒体流分类:
lPull—由客户端发起并控制的数据传输。超文本传输协议和文件传输协议都是pull协议。
lPush—由服务器端发起并控制的数据传输。实时传输协议(RTP)是一个用于流媒体的push协议。
 
2.3常用媒体格式(formats
下表列出了常用的音频(Table2)和视频(Table1)格式。在选用某种格式时,我们应该考虑对媒体质量的要求、对CPU的要求和对网络传输带宽的要求。
 
Format
Content Type
Quality
CPU Requirements
Bandwidth Requirements
Cinepak
AVI
QuickTime
Medium
Low
High
MPEG-1
MPEG
High
High
High
H.261
AVI
RTP
Low
Medium
Medium
H.263
QuickTime
AVI
RTP
Medium
Medium
Low
JPEG
QuickTime
AVI
RTP
High
High
High
Indeo
QuickTime AVI
Medium
Medium
Medium

Table 1: 常用视频格式
Format
Content Type
Quality
CPU Requirements
Bandwidth Requirements
PCM
AVI
QuickTime
WAV
High
Low
High
Mu-Law
AVI
QuickTime
WAV
RTP
Low
Low
High
ADPCM
(DVI,
IMA4)
AVI
QuickTime
WAV
RTP
Medium
Medium
Medium
MPEG-1
MPEG
High
High
High
MPEG
Layer3
MPEG
High
High
Medium
GSM
WAV
RTP
Low
Low
Low
G.723.1
WAV
RTP
Medium
Medium
Low

Table 2:  常用的音频格式 .
 
3.         媒体播放(media presentation
大部分基于时间的媒体都是音频或视频数据,它可以通过输出设备如扬声器(speaker)和监示器(monitor)输出。这些设备都是最常用的用于媒体数据输出的目标地(destination)。媒体数据也可以被传输到一些其它目标地,例如,保存到文件或传输到网络。一个用于媒体数据输出的目标地有时被称为数据汇集点(data sink)。
 
3.1播放控制(presentation contrals
当输出一个媒体流时,用户可以对其进行一般的控制操作。如停止、快进、重放等。
 
3.2    缓冲期(latency)
在大多数情况下,特别是在播放网络上的媒体数据时,播放不能立即开始。在播放前的这段时间被称为缓冲期(start latency)。多媒体的播放通常是合成多种类型(types)的媒体流将其同步播放。当播放多条同步的媒体数据流时,必须考虑每条媒体流的缓冲期,否则会出现多条媒体流在重放(playback)时不同步的情况。
 
4.媒体处理(media processing
在大多数情况下,媒体流的数据在播放前必须经过处理。通常在播放前要经过一系列的处理操作:
l如果媒体流是复合的,必须提取出所有的道(tracks)。
l如果这些道(tracks)是压缩的,他们必须被解码。
l如果必要,还要将这些道(tracks)转换为其它格式(format)。
l如果必要,还需要对这些已经解码的道(tracks)进行渲染。
然后这些道才能被传递到相应的输出设备。如果是存储媒体流,则处理过程会有所不同。例如,如果你想从摄像机捕获音频和视频将其存储到一个文件,处理过程如下:
l捕获音频和视频道(tracks)。
l对这些原始数据进行必要的渲染。
l每条道(tracks)被解码。
l将这些经过压缩的(compressed)道合成为一条单一的媒体流。
l将这条合成的媒体流存储到文件。
 
4.1分离器与复用器(demultiplexers and multiplexers
分离器的作用是从一个合成的媒体流中分离出每条道的媒体数据。复用器的作用是将单独的道的媒体数据合成为一条复合的媒体流。
 
4.2编解码器(codecs
一个编解码器的作用是对媒体数据进行压缩和解压缩。当一个道被编码,它将被压缩成一个易于存储和传输的格式(format);当它被解码,它将被解压成一个易于播放的格式(format)。
每种编解码器都有其相应的输入格式和输出格式。
 
4.3渲染器(effect filters)
渲染器的作用是产生特殊的效果,如模糊和回声。
渲染器通常可分为预处理效果和后处理效果渲染器。这主要由它们是在编解码过程前后进行决定。原则上,渲染应当是对未被压缩的(原始)数据进行。
 
4.4显示器(renderers
显示器是指宏观上的所有播放设备。对于音频,播放设备一般是指计算机的声卡,由它传递声音到扬声器(speakers)。对于视频,播放设备一般是指计算机的监视器(monitor)。
 
5.媒体捕获(media capture
基于时间的媒体可以捕获自一个实时的数据源,再对其进行处理(processing)和重放(playback)。例如可以通过麦克风捕获音频数据。捕获可以被看作是标准媒体处理模式的输入阶段。
一个捕获设备可能会捕获到多条媒体流。例如,一个摄像机可能会捕获到音频和视频。这些媒体流可能会被单独的捕获和处理或者合成为一条单一的流。合成流中会同时包含音频道(track和视频道(track)

本文转自zhangjunhd51CTO博客,原文链接:http://blog.51cto.com/zhangjunhd/25464,如需转载请自行联系原作者
相关文章
|
3月前
|
开发工具 Android开发 开发者
Android平台如何不推RTMP|不发布RTSP流|不实时录像|不回传GB28181数据时实时快照?
本文介绍了一种在Android平台上实现实时截图快照的方法,尤其适用于无需依赖系统接口的情况,如在RTMP推送、RTSP服务或GB28181设备接入等场景下进行截图。通过底层模块(libSmartPublisher.so)实现了截图功能,封装了`SnapShotImpl.java`类来管理截图流程。此外,提供了关键代码片段展示初始化SDK实例、执行截图、以及在Activity销毁时释放资源的过程。此方案还考虑到了快照数据的灵活处理需求,符合GB/T28181-2022的技术规范。对于寻求更灵活快照机制的开发者来说,这是一个值得参考的设计思路。
|
Web App开发 编解码 前端开发
VUE网页实时播放海康、大华摄像头RTSP视频流完全方案,300毫秒延迟,支持H.265、可多路同时播放
在遍地都是摄像头的今天,往往需要在各种信息化、数字化、可视化B/S系统中集成实时视频流播放等功能,海康、大华、华为等厂家摄像头或录像机等设备一般也都遵循监控行业标准,支持国际标准的主流传输协议RTSP输出,而Chrome、Firefox、Edge等新一代浏览器从2015年开始取消了NPAPI插件技术支持导致RTSP流无法直接原生播放了
3088 0
|
编解码 监控 数据安全/隐私保护
国标GB28181协议客户端开发(三)查询和实时视频画面
国标GB28181协议客户端开发(三)查询和实时视频画面
637 0
|
Web App开发 编解码 移动开发
移动端短语音消息音频格式选择
评估音频编码指标,除码率、采样率、和算法延迟以外,还要参考MOS、VBR/CBR、和基础算法等。其中,MOS(Mean OpinionScore)是语音编解码器的主观评估指标。MOS是一个广为接受的有统计意义的主观听音指标。上面音视频编解码器的列表没有把它包含进去,是因为同一个编解码器,在不同码率下,表现出来的MOS值是会变化的。对一个音频编解码器给出一个固定的MOS值,反而会起误导的作用。另外,虽然MOS值已经是主观的听觉测试评估结果,但是音频工程师在选用音频编解码器的时候,还要以自己亲身的听感作为最终的依据。
358 0
|
Web App开发 编解码 监控
如何在VUE中播放海康威视RTSP/RTMP/ISC平台/NVR视频流?延迟低于300毫秒?
近期在做摄像头监控视频在网页中播放的工作,现在大部分摄像头厂商如海康威视、大华、华为等都支持标准的RTSP协议,RTSP协议的优势是实时性高、流畅度度高,同时支持H.265和H.264,清晰度也更高,对于要求比较高的安防、交通等领域很适合。
1059 0
如何在VUE中播放海康威视RTSP/RTMP/ISC平台/NVR视频流?延迟低于300毫秒?
|
编译器
QT软件开发: 获取媒体详细信息(视频/音频)
QT软件开发: 获取媒体详细信息(视频/音频)
331 0
QT软件开发: 获取媒体详细信息(视频/音频)
|
存储 XML 编解码
RTSP 媒体协议流的录制方案及其覆盖策略详解
在安防和监控领域,RTSP 媒体协议流有很广泛的使用。本文将介绍一种针对 RTSP 媒体流的录制方案及其相应的覆盖策略。常见的实时录制功能支持三种模式,分别是云端录制、本地服务端录制和页面录制,今天我们介绍的录制方案属于云端录制。
417 0
RTSP 媒体协议流的录制方案及其覆盖策略详解
|
开发框架 监控 .NET
一个小时开发的直播推拉流软件来了
目前市面上直播推流的软件有很多,拉流也很常见。近期因为业务需要,需要搭建一整套服务端推流,客户端拉流的程序。随即进行了展开研究,花了一个小时做了个基于winfrom桌面版的推拉流软件。另外稍微啰嗦两句,主要怕你们翻不到最下面。目前软件还是一个简化版的,但已足够日常使用,比如搭建一套餐馆的监控,据我了解,小餐馆装个监控一般3000—5000,如果自己稍微懂点软件知识,几百元买几个摄像头+一台电脑,搭建的监控不足千元,甚至一两百元足够搞定了。这是我研究这套软件的另外一个想法
413 0
一个小时开发的直播推拉流软件来了
|
Web App开发 编解码 中间件
海康威视摄像头RTSP视频流嵌入到谷歌Chrome等WEB页面中实时播放方案(图文教程)
近期在做一个智慧城市项目,要求将海康威视、大华等摄像头RTSP视频流在Chrome、Firefox、Edge等浏览器中播放,并且要求延迟必须要低,能到多低就多低,最好是实时视频。 小编了解很多不同的方案,目前市面上大部分是转码转流方案,不仅需要服务器支持,并且需要服务器不停的转码转流,如果多路同时播放或者播放高清视频,非常容易出现卡顿、花屏等情况,延迟更是高达数秒甚至数分钟,对于一些延迟要求较高的项目来说,这简直是灾难性后果。
2901 0
海康威视摄像头RTSP视频流嵌入到谷歌Chrome等WEB页面中实时播放方案(图文教程)
|
Web App开发 编解码 监控
网页播放海康威视大华华为摄像头RTSP流,不需转码转流,延迟毫秒级,支持多路播放、H.264/H.265及1080P/2K/4K,支持抓图录像字幕
在遍地都是摄像头的今天,往往需要在各种信息化、数字化、可视化B/S系统中集成实时视频流播放等功能,海康、大华、华为等厂家摄像头或录像机等设备一般也都遵循监控行业标准,支持国际标准的主流传输协议RTSP输出,而Chrome、Firefox、Edge等新一代浏览器从2015年开始取消了NPAPI插件技术支持导致不再支持RTSP的原生播放
755 0