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,如需转载请自行联系原作者
相关文章
|
7天前
|
人工智能 搜索推荐 API
Cobalt:开源的流媒体下载工具,支持解析和下载全平台的视频、音频和图片,支持多种视频质量和格式,自动提取视频字幕
cobalt 是一款开源的流媒体下载工具,支持全平台视频、音频和图片下载,提供纯净、简洁无广告的体验
123 9
Cobalt:开源的流媒体下载工具,支持解析和下载全平台的视频、音频和图片,支持多种视频质量和格式,自动提取视频字幕
|
Web App开发 编解码 前端开发
VUE网页实时播放海康、大华摄像头RTSP视频流完全方案,300毫秒延迟,支持H.265、可多路同时播放
在遍地都是摄像头的今天,往往需要在各种信息化、数字化、可视化B/S系统中集成实时视频流播放等功能,海康、大华、华为等厂家摄像头或录像机等设备一般也都遵循监控行业标准,支持国际标准的主流传输协议RTSP输出,而Chrome、Firefox、Edge等新一代浏览器从2015年开始取消了NPAPI插件技术支持导致RTSP流无法直接原生播放了
3153 0
|
5月前
|
开发工具 Android开发 开发者
Android平台如何不推RTMP|不发布RTSP流|不实时录像|不回传GB28181数据时实时快照?
本文介绍了一种在Android平台上实现实时截图快照的方法,尤其适用于无需依赖系统接口的情况,如在RTMP推送、RTSP服务或GB28181设备接入等场景下进行截图。通过底层模块(libSmartPublisher.so)实现了截图功能,封装了`SnapShotImpl.java`类来管理截图流程。此外,提供了关键代码片段展示初始化SDK实例、执行截图、以及在Activity销毁时释放资源的过程。此方案还考虑到了快照数据的灵活处理需求,符合GB/T28181-2022的技术规范。对于寻求更灵活快照机制的开发者来说,这是一个值得参考的设计思路。
|
8月前
|
编解码 API 开发工具
FFmpeg获取音视频流信息
FFmpeg获取音视频流信息
178 1
FFmpeg获取音视频流信息
|
8月前
|
Web App开发
web接入海康相机视屏流 注意事项 - 编码H264
web接入海康相机视屏流 注意事项 - 编码H264
221 1
设计并实现同时支持多种视频格式的流媒体点播系统
设计并实现同时支持多种视频格式的流媒体点播系统
171 0
|
存储 编解码 数据可视化
漏刻有时数据可视化语音留言墙开发日志(微信录音&七牛云amr转换成mp3存储转码)
漏刻有时数据可视化语音留言墙开发日志(微信录音&七牛云amr转换成mp3存储转码)
88 0
|
安全 JavaScript 前端开发
如何让在线视频以自定义速度播放
现在看视频不来个两倍速(或者更快)都觉得在浪费生命。 特别是在看视频教程的时候,文字我们可以做到一目十行,但是视频呢,如果有字幕,我们甚至不用听清,用3倍速或者4倍速完全没有问题,尤其在看别人在线写代码的时候,速度快了,就觉得特别顺滑。
537 0
如何让在线视频以自定义速度播放
|
开发框架 监控 .NET
一个小时开发的直播推拉流软件来了
目前市面上直播推流的软件有很多,拉流也很常见。近期因为业务需要,需要搭建一整套服务端推流,客户端拉流的程序。随即进行了展开研究,花了一个小时做了个基于winfrom桌面版的推拉流软件。另外稍微啰嗦两句,主要怕你们翻不到最下面。目前软件还是一个简化版的,但已足够日常使用,比如搭建一套餐馆的监控,据我了解,小餐馆装个监控一般3000—5000,如果自己稍微懂点软件知识,几百元买几个摄像头+一台电脑,搭建的监控不足千元,甚至一两百元足够搞定了。这是我研究这套软件的另外一个想法
428 0
一个小时开发的直播推拉流软件来了
|
Web App开发 Java API
浅析webrtc中音频的录制和播放流程
本文是基于PineAppRtc项目github.com/thfhongfeng… 在webrtc中音频的录制和播放都是封装在内部,一般情况下我们也不需要关注,直接使用即可。 但是最近有一个需求,需要将我们自己的数据进行传输,所以就需要将这些接口暴露出来使用。所以就需要去研究一下它的源码,就有了这篇文章。
966 0