精华内容
参与话题
问答
  • 本文档主要介绍海康威视设备直播预览RTSP、录像回放RTSP、流媒体取流的RTSP URL和IE直接预览、回放的HTTP URL。 RTSP为取流协议,取到码流后需要解码显示,可以通过VLC播放器或者EasyPlayer播放器进行测试,IE等...

    本文档主要介绍海康威视设备直播预览RTSP、录像回放RTSP、流媒体取流的RTSP URL和IE直接预览、回放的HTTP URL。

    RTSP为取流协议,取到码流后需要解码显示,可以通过VLC播放器或者EasyPlayer播放器进行测试,IE等浏览器网页不支持RTSP协议直接取流预览或者回放,需要安装OCX插件,这也是目前大部分安防厂家的做法。

    目前也有很多支持RTSP进行网页无插件直播的流媒体服务,例如EasyNVR就是专门做这种安防RTSP转互联网RTMP/HLS(m3u8)/FLV无插件H5直播的流媒体服务中间件;

    网页上需要跳过登录界面直接访问我们设备的预览或者回放画面,可以使用文档中所述的HTTP的URL实现。

    注:

    1)URL中“:”“?”“&”等符号均为英文半角。

    2)RTSP取流和HTTP 访问URL都需要设备支持,如下所示两种控件的设备均可支持。

     

    一、海康RTSP取流URL地址规则

    1.1 预览取流

    设备预览取流的RTSP URL有新老版本,2012年之前的设备(比如V2.0版本的Netra设备)支持老的取流格式,之后的设备新老取流格式都支持(这里不得不再说一下海康是国内视频硬件独一档)

    • 【海康老版本,目前已经非常少见了】

    URL规定:

    rtsp://username:password@<ipaddress>/<videotype>/ch<number>/<streamtype>

    注:VLC或者EasyPlayer可以支持解析URL里的用户名密码,实际发给设备的RTSP请求URL不支持带用户名密码。

    详细描述:

     

    举例说明:

    DS-9016HF-ST的IP通道01主码流:

    rtsp://admin:12345@172.6.22.106:554/h264/ch33/main/av_stream

    DS-9016HF-ST的模拟通道01子码流:

    rtsp://admin:12345@172.6.22.106:554/h264/ch1/sub/av_stream

    DS-9016HF-ST的零通道主码流(零通道无子码流):

    rtsp://admin:12345@172.6.22.106:554/h264/ch0/main/av_stream

    DS-2DF7274-A的第三码流:

     rtsp://admin:12345@172.6.10.11:554/h264/ch1/stream3/av_stream

     

    • 【海康新版本,DS系列】

    URL规定:

    rtsp://username:password@<address>:<port>/Streaming/Channels/<id>(?parm1=value1&parm2-=value2…)

    注:VLC或者EasyPlayer可以支持解析URL里的用户名密码,实际发给设备的RTSP请求不支持带用户名密码。

    详细描述:

     

    举例说明:

    DS-9632N-ST的IP通道01主码流:

    rtsp://admin:12345@172.6.22.234:554/Streaming/Channels/101?transportmode=unicast

    DS-9016HF-ST的IP通道01主码流:

    rtsp://admin:12345@172.6.22.106:554/Streaming/Channels/1701?transportmode=unicast

    DS-9016HF-ST的模拟通道01子码流:

    rtsp://admin:12345@172.6.22.106:554/Streaming/Channels/102?transportmode=unicast  (单播)

    rtsp://admin:12345@172.6.22.106:554/Streaming/Channels/102?transportmode=multicast (多播)

    rtsp://admin:12345@172.6.22.106:554/Streaming/Channels/102 (?后面可省略,默认单播)

    DS-9016HF-ST的零通道主码流(零通道无子码流):

    rtsp://admin:12345@172.6.22.106:554/Streaming/Channels/001

    DS-2DF7274-A的第三码流:

    rtsp://admin:12345@172.6.10.11:554/Streaming/Channels/103

    注:前面老URLNVR>=64路的除外)的IP通道从33开始;新URL,通道号全部按顺序从1开始。

     

    1.2 录像回放取流RTSP规则

    URL规定:

    rtsp://username:password@<address>:<port>/Streaming/tracks/<id>(?parm1=value1&parm2-=value2…)

    注:VLC或者EasyPlayer可以支持解析URL里的用户名密码,实际发给设备的RTSP请求不支持带用户名密码。

    详细描述:

     

    举例说明:

    DS-9016HF-ST的模拟通道01:

    rtsp://admin:12345@172.6.22.106:554/Streaming/tracks/101?starttime=20120802t063812z&endtime=20120802t064816z

    DS-9016HF-ST的IP通道01:

    rtsp://admin:12345@172.6.22.106:554/Streaming/tracks/1701?starttime=20131013t093812z&endtime=20131013t104816z

    表示以单播形式回放指定设备的通道中的录像文件,时间范围是starttimeendtime,其中starttimeendtime的格式要符合ISO 8601。具体格式是YYYYMMDDTHHmmSS.fractionZY是年,M是月,D是日,T是时间分格符,H是小时,M是分,S是秒,Z是可选的、表示Zulu(GMT) 时间。

    注意:很多时候我们用命令行来验证RTSP回放流的时候,一定要将整个RTSP-URL用双引号包括起来,“RTSP-URL”,因为CMD里面&符号是特殊字符,不用双引号包起来,整个地址会被切割分成几个部分;

     

    1.3 海康流媒体服务取流RTSP规则

    • 【流媒体V4.0】iVMS-4200 V2.0配套流媒体服务器

    URL描述:

    注:Devicehc8为固定字符,不可更改。

     

    举例说明:

    通过流媒体服务器172.6.24.15从设备172.6.22.106取通道01主码流:

    rtsp://172.6.24.15:554/Devicehc8://172.6.22.106:8000:0:0?username=admin&password=12345

     

    • 【流媒体V2.0】

    URL描述:

    举例说明:

    rtsp://172.6.24.15:554/172.6.22.106:8000:HIK-DS8000HC:2:0:admin:12345/av_stream

    注:流媒体2.0的取流URL不是标准的RTSP协议,必须使用流媒体SDK(客户端)才支持取流的,放在这里只是为了给流媒体4.0做参照的。

     

    二、通用摄像机RTSP取流URL地址规则

    现在实际上现在已经不用再这么复杂地获取RTSP的取流地址了,因为大部分的IPC或者NVR都基本支持了Onvif协议,通过Onvif Device Test Tool或者EasyNVR这样的工具,可以直接发现到设备的RTSP流地址,不用再自己来根据不同厂家的规则拼接了,以EasyNVR为例:

    EasyNVR

    EasyNVR

     

    EasyNVR

     

    ✈ 更多视频解决方案资源汇总

    © TSINGSEE Team:http://www.tsingsee.com
    青犀TSINGSEE

    展开全文
  • 今天发现二哥在搞流媒体,顿时来了兴趣(之前在考试维护的时候经常听老师说P2P等),追问之下之前林哥搞成功过,而且写了一系列博客;于是乎便翻开博客,认真看了看,写的非常不错:从概念到安装实现(linux和...

    强烈推荐一个大神的人工智能的教程:http://www.captainbed.net/zhanghan

    【前言】

        今天发现二哥在搞流媒体,顿时来了兴趣(之前在考试维护的时候经常听老师说P2P等),追问之下之前林哥搞成功过,而且写了一系列博客;于是乎便翻开博客,认真看了看,写的非常不错:从概念到安装实现(linux和windows)再到性能测试对比非常不错(详见:http://blog.csdn.net/u012407484/article/category/2732453);

        在看博客之前和二哥交流,自己当时认为流媒体是P2P,看了林哥的博客后对流媒体的概念了解了,感觉不太对劲,于是乎马不停蹄在网上度娘了一把进行验证,果然发现流媒体和P2P是不同的两个东西,但是P2P技术在流媒体领域中应用比较广泛,也难怪之前自己将两者混为一谈。

        通过在网上查资料和林哥的博客自己对传统媒体,流媒体,加P2P的流媒体技术有了更多的了解,在此与大家共享。

    【流媒体进化之路】

        1、传统媒体:刚开始的时候大家在网上看视频或音频等媒体是采用传统媒体的方式:从服务器下载完后再能进行播放:

                       

        2、流媒体:随着人类生活越来越丰富,品味越来越高(比如:视频要超清滴等),逐渐发现传统媒体的方式不能满足人类的需要(比如:要看个超清的电影可能需要缓冲4个小时);于是乎流媒体技术应运而生:

                        

        3、加P2P的流媒体:随着互联网的快速发展,利用互联网进行娱乐的人越来越多,相信大家有这样体会,每到上网高峰期自己看视频卡的要死;这便是普通流媒体中存在一个问题,服务器的压力太大,服务器性能和带宽承受不住;很简单一个解决方案:加大服务器的带宽,提高服务器的性能,或许会暂时解决问题,但是当客户再多,服务器的性能和带宽又承受不住,实践表明这种客户增长速度要远大于服务器和带宽的增长。于是乎应用P2P技术流媒体应运而生:

         (1)最开始只有客户A获取资源示意图:

               

         (2)过一会儿后客户B获取资源示意图:

                

         (3)再过一会儿客户C访问资源示意图:

             

        (4)不难看出采用P2P技术后刚开始是从服务器上获取初始资源,随着客户机不断获取资源,后来的客户机可根据相应的算法判断到离其最近的机器上(并不一定是客户机哈)有自己想要的资源然后去获取之;不难看出当客户机越多,资源分布在客户机中的概率越高,自然而然获取资源更快;所带来的体验更好(比如:看视频时,同时看的人越多反而越流畅了)。

    【总结】

        1、从传统媒体—>流媒体—>含P2P流媒体:技术复杂度逐渐递增,人的体验越来越好;

        2、随着人类的生活越来越丰富需求越来越高,从而推动技术在不断的发展;   
        3、学习的兴趣来源于经历来源于好奇心。

    展开全文
  • 1、本地:采用javaCV(安卓和java平台推荐javaCV)、ffmpeg、openCV或者jmf可以很方便的获取到本地摄像头流媒体 javaCV系列文章: javacv开发详解之1:调用本机摄像头视频 javaCV开发详解之2:推流器实现,推...

    快速传送至:javacv入门指南:序章

    快速传送至:从零开始开发和搭建直播平台-教程汇总篇

    javaCV系列文章:

    javacv开发详解之1:调用本机摄像头视频

    javaCV开发详解之2:推流器实现,推本地摄像头视频到流媒体服务器以及摄像头录制视频功能实现(基于javaCV-FFMPEG、javaCV-openCV)

    javaCV开发详解之3:收流器实现,录制流媒体服务器的rtsp/rtmp视频文件(基于javaCV-FFMPEG)

    javaCV开发详解之4:转流器实现(也可作为本地收流器、推流器,新增添加图片及文字水印,视频图像帧保存),实现rtsp/rtmp/本地文件转发到rtmp流媒体服务器(基于javaCV-FFMPEG)

    javaCV开发详解之5:录制音频(录制麦克风)到本地文件/流媒体服务器(基于javax.sound、javaCV-FFMPEG)

    javaCV开发详解之6:本地音频(话筒设备)和视频(摄像头)抓取、混合并推送(录制)到服务器(本地)

    javaCV开发详解之7:让音频转换更加简单,实现通用音频编码格式转换、重采样等音频参数的转换功能(以pcm16le编码的wav转mp3为例)

    javaCV开发详解之8:转封装在rtsp转rtmp流中的应用(无须转码,更低的资源消耗,更好的性能,更低延迟)

    javaCV开发详解之9:基于gdigrab的windows屏幕画面抓取/采集(基于javacv的屏幕截屏、录屏功能)

    javaCV开发详解之10:基于dshow调用windows摄像头视频和音频,想要获取屏幕画面首选gdigrab

    补充篇:

    javaCV开发详解补充篇:基于avfoundation的苹果Mac和ios获取屏幕画面及录屏/截屏以及摄像头画面和音频采样获取实现

    音视频编解码问题:javaCV如何快速进行音频预处理和解复用编解码(基于javaCV-FFMPEG)

    音视频编解码问题:16/24/32位位音频byte[]转换为小端序short[],int[],以byte[]转short[]为例

    实现给图片增加图片水印或者文字水印(也支持视频图像帧添加水印)

    java原生实现屏幕设备遍历和屏幕采集(捕获)等功能

    流媒体直播实时视频延迟时间排查和剖析

    javacv文字识别系列:

    javaCV文字识别之1:基于google的tesserac ocr识别图片中的文字,跨平台支持英文中文简体繁体等各种字符识别

    javaCV文字识别之2:视频文字识别和视频提取字幕文字字符

    javacpp-ffmpeg系列:

    javacpp-FFmpeg系列之1:视频拉流解码成YUVJ420P,并保存为jpg图片

    javacpp-FFmpeg系列之2:通用拉流解码器,支持视频拉流解码并转换为YUV、BGR24或RGB24等图像像素数据

    javacpp-FFmpeg系列之3: 图像数据转换(BGR与BufferdImage互转,RGB与BufferdImage互转)

    javacpp-FFmpeg系列补充:FFmpeg解决avformat_find_stream_info检索时间过长问题

    javacpp-opencv系列:

    一、javaCV图像处理之1:实时视频添加文字水印并截取视频图像保存成图片,实现文字水印的字体、位置、大小、粗度、翻转、平滑等操作

    二、javaCV图像处理之2:实时视频添加图片水印,实现不同大小图片叠加,图像透明度控制

    三、javacv图像处理3:使用opencv原生方法遍历摄像头设备及调用(方便多摄像头遍历及调用,相比javacv更快的摄像头读取速度和效率,方便读取后的图像处理)

    四、javacv图像处理系列:国内车辆牌照检测识别系统(万份测试准确率99.7%以上)

    一、本地推送端

    1、本地:采用javaCV(安卓和java平台推荐javaCV)、ffmpeg、openCV或者jmf可以很方便的获取到本地(windows、macos、安卓、ios、linux或者其他设备)摄像头画面或者视频文件以及其他流媒体。

    以下几篇是视频源抓取/采集篇:

    javacv开发详解之1:调用本机摄像头视频

    javaCV开发详解之2:推流器实现,推本地摄像头视频到流媒体服务器以及摄像头录制视频功能实现(基于javaCV-FFMPEG、javaCV-openCV)

    javaCV开发详解之5:录制音频(录制麦克风)到本地文件/流媒体服务器(基于javax.sound、javaCV-FFMPEG)

    javaCV开发详解之6:本地音频(话筒设备)和视频(摄像头)抓取、混合并推送(录制)到服务器(本地)

    javaCV开发详解之9:基于gdigrab的windows屏幕画面抓取/采集(基于javacv的屏幕截屏、录屏功能)

    javaCV开发详解之10:基于dshow调用windows摄像头视频和音频,想要获取屏幕画面首选gdigrab

    javaCV开发详解补充篇:基于avfoundation的苹果Mac和ios获取屏幕画面及录屏/截屏以及摄像头画面和音频采样获取实现

     

    2、监控(第三方摄像头):通过设备sdk或者rtsp直播流获取流媒体源

    以下是以摄像机的rtsp地址为例(其中第4章是转码,第8章是转封装):

    javaCV开发详解之4:转流器实现(也可作为本地收流器、推流器,新增添加图片及文字水印,视频图像帧保存),实现rtsp/rtmp/本地文件转发到rtmp流媒体服务器(基于javaCV-FFMPEG)

    javaCV开发详解之8:转封装在rtsp转rtmp流中的应用(无须转码,更低的资源消耗,更好的性能,更低延迟)

     

    二、转流端

    直播:通过ffmpeg(推荐),live555将接收rtsp或者字节码流并转为flv格式发布到rtmp流媒体服务器(流媒体服务器必须先建好)

    hls原理同上

    注意:rtmp只支持flv格式封装的视频流

    ffmpeg服务实现方式实例请参考:

    http://blog.csdn.net/eguid_1/article/details/51777716

    http://blog.csdn.net/eguid_1/article/details/51787646

    也可以参考javaCV的转流器实现:javaCV开发详解之4:转流器实现,实现rtsp/rtmp/本地文件转发到rtmp服务器  

    java封装FFmpeg命令,支持原生ffmpeg全部命令,实现FFmpeg多进程处理与多线程输出控制(开启、关闭、查询),rtsp/rtmp推流、拉流

    转封装实现:

    javaCV开发详解之8:转封装在rtsp转rtmp流中的应用(无须转码,更低的资源消耗,更好的性能,更低延迟)

    三、流媒体服务器

    目前主流的流媒体服务器有:srs、nginx-rtmp(以及nginx其他流媒体插件)、fms、red5(java)、flazr

    本地视频:直接通过流媒体服务器解码并推送视频流

    直播流:通过开启udp/rtp/rtsp/rtmp/hls等等流媒体服务,从ffmpeg/live555获取推送过来的实时视频流并发布到rtmp/hls直播流并推送(可以边直播边保存)

    rtmp、flv这两种是web领域主流的直播协议,flv和hls是主流点播协议;使用rtp或rtsp协议的一般都是局域网监控设备。

    流媒体协议选择:rtmp基于tcp协议,rtmp能够保持1-3秒左右延迟,flv等同于rtmp。hls(m3u8)是基于http协议,实时性特别差(苹果在设计这套协议的时候本来就不是用来作为直播流的,苹果官方也是推荐hls作为点播协议),想要用hls保证实时性是很难的,虽然可以把每个ts切的很小,但是每个ts的请求解析也是要耗时的,还有切ts分片本身也耗时耗资源,而且对硬盘要求也很高,大量碎片文件会让硬盘吃不消)。

    实时性要求特高的,建议使用基于udp协议的一些流媒体协议,比如国内几家直播平台会自己定义一套udp私有协议流。

    基于tcp和udp两种流媒体协议区别就是tcp会强制同步,udp是数据发出去就不管了。

    所以最终的方案就是:强同步但是实时性要求不高用基于tcp协议的,强实时性弱同步就udp。外网尽量不用rtsp,丢包率高的让人瘆得慌,现在国内主流直播方案是:flv(首选)>rtmp>udp私有协议>hls,如果是点播则是hls>flv>mp4。

    补充:nginx-rtmp流媒体服务器搭建实例:http://blog.csdn.net/eguid_1/article/details/51749830

    nginx-rtmp配置指令详细含义和用法:http://blog.csdn.net/eguid_1/article/details/51821297

    四、播放端(收流端)

    直播:通过flex(flash)播放器或者第三方播放器(videoJS,ckplayer,VideoLAN 等...)调用流媒体服务器的流媒体源解码并播放,如果不需要兼容低版本IE,可以采用HTML5的webSocket播放器,videoJS是flash/html5双核播放器。

     

    视频:通过html自带播放器、flex(flash)播放器或者第三方播放器(videoJS,ckplayer,VideoLAN 等...)进行播放

    videoJS/ckplayer播放器二次开发支持rtmp直播、hls直播及普通视频播放:http://blog.csdn.net/eguid_1/article/details/51898912

     

    一般使用videoLAN播放器作为测试工具,用于测试音视频流发布状况

    补充:

    1、如果是采用nginx服务器,它提供的rtmp模块可以发布rtmp直播、录播及hls,nginx可以把ffmpeg整合进去方流媒体后期处理(加水印等)。

    2、java是可以调用ffmpeg的,通过jni的方式有两种方法:

    2.1、javaCV一直在更新,作者是deeplearning4j的成员,JavaCV已经更新到了1.5x版本,支持通过javacpp调用ffmpeg,javaCV目前整合了几十种流媒体处理框架,是跨平台的强大流媒体处理利器 

    2.2、javaAV(目前最新0.7,release最新0.5)提供了对java调用ffmpeg的支持,当前已停止更新

     

    补充:为什么没有基于原生java(或者说自带GC的语言)的流媒体框架,原因来自GC,也就是java引以为豪的自动垃圾回收机制(真的是成也萧何,败也萧何)

    为什么呢?

    大家知道,直播(顾名思义,实时视频转发),这种实时性项目会产生大量的对象,这样会导致两种情况:

    1、产生大量对象后占据的内存资源得不到及时释放,于是虚拟机内存溢出。

    2、产生大量对象导致GC满负荷运行进行资源回收,会严重占用系统资源,导致系统运行迟滞,影响系统运行性能和实时性等等。

    展开全文
  • 流媒体的书籍,通信计算机方向可看!流媒体的书籍,通信计算机方向可看!流媒体的书籍,通信计算机方向可看!流媒体的书籍,通信计算机方向可看!
  • 流媒体/流媒体文件格式详解

    千次阅读 2017-05-31 20:34:41
    摘 要 流媒体文件格式在流媒体系统中占有重要地位,设计合理的文件格式是提高流媒体服务器工作效率最直接和最有效的办法。该文在剖析常用流媒体系统和文件格式的基础上,特别地对美国xiph.org基金会的开源流媒体...

    摘  要   流媒体文件格式在流媒体系统中占有重要地位,设计合理的文件格式是提高流媒体服务器工作效率最直接和最有效的办法。该文在剖析常用流媒体系统和文件格式的基础上,特别地对美国xiph.org基金会的开源流媒体工程Ogg文件格式子项目做了深入的分析,指出Ogg格式对媒体编码数据的存储读取和传输具有简洁性,Ogg格式的映射与逆映射与媒体编码数据具有相对独立性,能够有效提高流媒体服务器的工作效率。

    1 引言
          流媒体是指在Internet/Intranet中使用流式传输技术的连续时基媒体,如音频、视频等多媒体文件。文件格式和传输协议是流媒体应用的主要技术。从不同的角度看,流媒体数据有三种格式:压缩格式、文件格式、发布格式。其中压缩格式描述了流媒体文件中媒体数据的编码、解码方式;流媒体文件格式是指服务器端待传输的流媒体组织形式,文件格式为数据交换提供了标准化的方式;流媒体发布格式是一种呈现给客户端的媒体安排方式。本文所讨论的格式是指第二种:流媒体文件格式。特别地分析了一种开源流媒体文件格式:Ogg。它是美国xiph.org基金会开发的开源流媒体工程的一个子项目,它是应其开源音/视频媒体压缩编码格式Vorbis/Theora等的存储与传输需要而设计的。
        本文在研究和分析已有流媒体系统的基础上,结合在研发新的流媒体系统中的经验和教训,对流媒体文件格式做系统和深入的剖析,旨在深入理解流媒体系统和找到提高流媒体系统工作效率的方法。

    2 流媒体文件格式分析

    2.1 文件格式在流媒体系统中的重要性

         一个简化的流媒体系统由流媒体服务器、客户端和传输网络组成,流媒体系统的核心是流媒体服务器。随着流媒体技术研究的深入和流媒体应用的扩展,如何提高流媒体系统的工作效率,主要指标体现为如何提高服务器并发媒体流的数量,这是一个被广泛关注的课题。它取决于服务器处理每个流的效率,决定了一个服务器能够同时为多少客户服务,其成果不但具有理论价值,更具有极大的经济价值。 
         图1的圆圈内标出了影响流媒体系统性能的一些主要因素。如果对其中每个因素仔细分析判断,可以发现对于一个现有的流媒体服务器而言,能有效提高其效率的手段并不多。例如:提升客户端、服务器端的硬件配置,只能获得性能提高,工作效率没有得到提高;实时传输、控制协议是人们经过多年的大量应用实践总结,由IETF因特网工程任务组确认的媒体流传输共同标准,是必须遵守的标准,是无法轻易改变的;节目源的质量、压缩方式等因素对于服务器而言是不可预知或者是不可控制的。那么在这些客观因素无法改变的情况下,优化流媒体文件格式为提高流媒体服务器的工作效率提供了可能。
        流媒体文件格式能够对服务器的工作效率产生影响是由流服务器工作方式的特点决定的。流服务器的主要工作任务是通过直播或点播的方式向用户提供流媒体内容,它输入磁盘上存储的流媒体文件,然后进行实时传输协议封装后再通过 IP网络输出给客户端。简言之,其工作流程为3 步:读取、封装、发送。由于每发送一个媒体流都需要启动一个流程,并且所有流程都需要实时进行,可见当一个流服务器并发几千个流时,每个流程工作效率的细小区别都会对服务器工作效率造成很大的影响。

    图1  简化的流媒体系统结构及其影响因素
        每个工作流程的输入是流媒体文件,输出是媒体数据包。输入、输出数据的内容是没有改变的,都是多媒体压缩码流,两者之间只有格式的不同,所以从数据流角度来看,服务器的主要工作其实是一个格式转换的过程。由于媒体数据包的格式是由传输协议事先确定的,那么流媒体文件格式是否能够方便服务器读取、封装就决定了服务器的工作量。

    2.2  流媒体文件格式的分析与比较

        流媒体文件在流媒体系统中具有重要地位,文献[2]分析了具有代表性的QuickTime电影文件(mov)和 Microsoft Media Server的电影文件(asf),对其文件格式和相关环节做了深入剖析。发现这些文件格式对服务器工作效率存在如下负面影响:
        (1)磁盘控制器访问吞吐量低。每次封装一个媒体数据包需要读取一帧数据,一般每帧大小为1K左右,每秒需要25帧,这造成对磁盘频繁访问,吞吐量低。
        (2)对于QuickTime Mov文件格式,媒体数据没有经过预处理,服务器每发一个包都需要从hint轨中获得打包时需要的相关参数,实时读取媒体数据、封装、发送,对CPU占用率很大。
        (3)对于Microsoft Asf文件格式,媒体数据在Packet中时已经是mms包的半成品,服务器节省了截取媒体流的时间,但仍然需要服务器选择媒体流来组织mms包。并且,Packet中的数据不全是需要发送的数据,浪费了内存空间和磁盘IO时间。  
         文献[3]提出了一种新的流媒体文件格式NMF,该格式具有如下基本结构(如图2所示)和特点:

    图2 NMF文件结构
        NMF流媒体文件由头文件和体文件构成。头文件主要包含文件描述、媒体描述、流描述等必要的信息;体文件包含全部的媒体数据。一个NMF由一个头文件和若干个体文件构成,同一媒体源不同的流(不同的传输协议或不同的码速率)存放在不同的体文件中,此结构用来实现多码速率切换/智能流技术和兼容现有的流媒体播放器。头文件和体文件的功能划分原则是:当服务器和客户建立连接时(在发送媒体数据之前),只需要从头文件中读数据;当服务器和客户建立连接后,只需要从文件体中读取媒体数据。这样,服务器中各个模块间耦合减少,效率提高。由于头文件和体文件的相对独立,使文件具有很强的可扩展性,并且使得利用硬件进行封装、发送也成为可能。
        NMF的核心思想就是充分利用预处理过程,将原始媒体文件组织成方便服务器处理的格式,减少实时封装和发送时的工作量,同时增加文件结构的兼容性和可扩展性,以提高流服务器的工作效率,增加并发流数量。

    3  Ogg 文件格式结构

    3.1 文件格式在流媒体系统中的重要性

         逻辑流以页(page)为单位组织链接成物理流,如图3所示:

    图3   Ogg 文件的组织形式
        图3中的文件链接了两个物理流,A、B和C三个逻辑流组成一个物理流,逻辑流D单独是一个物理流。一个物理流中的所有逻辑流的bos_page都必须在物理位置上相邻,如图3所示*A*、*B*、*C*三个bos_page的位置。
        bos:beginning of stream;    eos:end of stream
         映射到Ogg格式的媒体(如vorbis音频,Theora视频)有相关详细定义,这些定义使得这些媒体之间有更具体的约束关系。Ogg 本身并没详细说明多个并发媒体流之间的时间关系,这需要并发媒体流在映射到Ogg格式的时刻来指定,通常他们之间的交错关系是按他们产生的时间先后顺序来排列。

    3.2 Ogg page 页结构

        每个页之间相互独立,都包含了各自应有的信息,页的大小是可变的,通常为4K-8KB,最大值不能超过65307bytes(27+255+255*255=65307)。页头部格式如图4。
        页头部各字段域详细说明参见文献[4]:(小端字节序列格式LSB)。
        ⑴ capture_pattern: 模式捕获域,4个字节,表示页的开始,其作用是分离Ogg封装格式还原媒体编码时识别新页的作用,它包含了四个幻数(ASCII字符集):
    0x4f 'O'    0x67 'g'    0x67 'g'     0x53 'S'
         ⑵ stream_structure_version:1个字节,表示当前Ogg文件格式的版本,目前为0。

    图4 Ogg页头部结构
        ⑶ header_type_flag:头部类型标识,1个字节。标识当前页具体类型。其设置分三种情况:
        *  bit 0x01  若已设置,页包含的媒体编码数据于前一页同属于一个逻辑流的同一packet。若未设置,本页是一个新的packet。
        *  bit 0x02   设置,表示逻辑流的第一个页bos。未设,不是第一个页。
        *  bit 0x04   设置,表示逻辑流的最后一页eos。未设,不是最后一页。
        ⑷ granule_position:8个字节(字节6-字节13),包含了媒体编码相关参数信息。对于音频流,包含了到本页为止逻辑流在PCM中采样编码的总次数。对于视频流,包含了逻辑流到本页为止视频帧编码的总次数。其值若为-1,则说明到此页为止,逻辑流的packet还未结束。
        ⑸ bitstream_serial_number:流序列号,4字节,表示本页所属逻辑流与其他逻辑流相区别的序号。
        ⑹ page_sequence_number: 表明了本页在逻辑流中的序列号,Ogg解码器能据此识别有无页丢失。
        ⑺ CRC_checksum: 循环冗余校验码校验和,4字节域,包含页的32bit CRC校验和(包括页头部零CRC校验和页数据校验),它的产生多项式为:0x04c11db7。
        ⑻ number_page_segments:1字节,给定了在本页的segment_tabale域中所出现的segement个数,其最大值为255segments(每片255个字节),即页头部第26个字节的取值范围为:0x00-0xff (0-255)。页最大物理尺寸为65307bytes,小于64KB。
        ⑼ segment_table:逻辑流中的每个packet每个segment长度的取值(lacing values,除了每个packet的最后一个segment小于255外,其它segment都为255),这些值以segment出现的先后顺序依次排列。此域的字节数为number_page_segments域所表示的数字(即在0-255之间)。
    byte     value
      27       0xff (255)
           [.................  ]
           n-1      0xff (255)
    n        0x00-0xfe (0-254, n=num_segments+26)
    页头部长度的字节数:
       header_size = 27 + number_page_segments [Byte] 
       即页头部长度为上述9个域名所表述占据的字节数之和。
    页的总长度:
      page_size = header_size + sum(lacing_values: 1...number_page_segments)   [Byte]
    即页的总长度为页头部长度加上紧随其后的若干segments长度之和(净载荷长度)。

    3.3  Ogg封装处理过程

        (1)音视频编码在提供给Ogg封装之前是以具有包边界的“Packets”形式呈现的,包边界依赖于具体的编码格式。如图5所示。
        (2)将逻辑流的各个包进行分片segmentation,每片大小固定为255Byte,但包的最后一个segment通常小于255字节。因为packet的大小可以是任意长度,由具体的媒体编码器来决定。
        (3)进行页封装,每页都被加上页头,每页的长度可不等,由具体情况而确定。页头部segment_table域告知了 “lacing_value”值的大小,即页中最后一个segment的长度(可以为0,或小于255)。一次处理一个packet,此packet被封装成一个或多个page页(page的长度设定了上限,一般为4kB);下一个packet必须用新的page开始封装,由首部字段域header_type_flag的设置规定来表示。
        (4)多个已被页格式封装好的逻辑流(如语音、文本、图片、音频、视频等)按应用要求的时序关系合成物理流。

    3.4  Ogg文件的映射与逆映射

        用Ogg文件格式封装好压缩编码媒体流可用于存储(磁盘文件)或直接传输(TCP或管道),这是因为Ogg比特流格式提供了封装/同步、差错同步捕获、寻找标记以及其它足够的信息使得这种分散开的数据能够完全地还原为封装之前的具有包边界“packet”形式的压缩编码媒体流,恢复到这种原来媒体流就具有的包边界形式不需要依赖于针对压缩编码的解码器。也就是说Ogg映射与逆映射和媒体流的压缩编码、解码具有相对独立性。

    图5  Ogg封装流程示意图
        Ogg文件需要解封装的情况有两种:(1)播放器要对媒体流解码之前;(2)对媒体流进行RTP/UDP传输之前。解封装的过程就是ogg逆映射过程,即还原为具有包边界“packet”形式的媒体流,同时以预先填充好了的RTP首部字段与相应一段媒体数据捆绑,形成RTP封包。此过程便是媒体流从Ogg格式到RTP格式的转换过程。
        将以packet为单元的媒体流映射为以page为单元的Ogg格式比特流,其中间经过了segment的划分和重组环节,但方便了对媒体流的存储与传输(TCP)。对源缓冲区媒体数据(packet)的操作,需建立几个中间环节的数据结构,只需将切割的媒体数据在内存移动一次,操作指向媒体数据的指针便能达到媒体数据迁移到目的缓冲区(page)的意图,其过程可用两个函数转换来表述:
    ogg_stream_packetin()àogg_stream_pageout()。 将Ogg格式比特流逆映射还原为packets媒体流,以备播放解码或以RTP封装进行UDP传输 。其中间环节是把page中的segment单元数据按顺序重组为packet,同样媒体数据在内存中的复制只有一次,其过程可用三个函数转换来表述:ogg_sync_pageout()à ogg_stream_pagein ()à ogg_stream_packetout(),媒体数据复制发生在第一个函数ogg_sync_pageout()。 
    Ogg映射与逆映射的功能都体现在ogg函数库中,当前最新版本为libogg-1.1.3。 

    4 结束语   

           Ogg格式是在吸收其它流媒体文件格式优点的基础上针对具有“packet”包边界形式的媒体流而制定的利于其存储和传输的开源流媒体文件格式,在icecast流服务器的传输中得到了很好的应用;根据icecast官方网站公布其测试结果,在GB主干网的条件下对Oggvorbis音频传输的客户端并发流可达14000个。更为重要的是,作为流媒体技术的核心环节,大多数流媒体文件格式至今仍没有完全公开,且受专利保护。要在流媒体技术和应用飞速   发展的今天占得一席之地,遵从GNU/GPL协定,走开源之路,发展不受知识产权约束的流媒体文件格式是紧追先进流媒体技术的较佳选择。 

    几种常见的流媒体格式文件:

    微软高级流格式ASF简介

    Microsoft公司的Windows Media的核心是ASF(Advanced Stream Format)。微软将ASF 定义为同步媒体的统一容器文件格式。ASF是一种数据格式,音频、视频、图像以及控制命令脚本等多媒体信息通过这种格式,以网络数据包的形式传输,实现流式多媒体内容发布。

    ASF最大优点就是体积小,因此适合网络传输,使用微软公司的最新媒体播放器(Microsoft Windows Media Player)可以直接播放该格式的文件。用户可以将图形、声音和动画数据组合成一个ASF格式的文件,当然也可以将其他格式的视频和音频转换为ASF格式,而且用户还可以通过声卡和视频捕获卡将诸如麦克风、录像机等等外设的数据保存为ASF格式。另外,ASF格式的视频中可以带有命令代码,用户指定在到达视频或音频的某个时间后触发某个事件或操作。

    ASF的特征

    可扩展的媒体类型- ASF文件允许制作者很容易地定义新的媒体类型。ASF格式提供了非常有效的灵活地定义符合ASF文件格式定义的新的媒体流类型。任一存储的媒体流逻辑上都是独立于其他媒体流的,除非在文件头部分明显地定义了其与另一媒体流的关系。

    部件下载-特定的有关播放部件的信息(如,解压缩算法和播放器)能够存储在ASF 文件头部分,这些信息能够为客户机用来找到合适的所需的播放部件的版本---如果它们没有在客户机上安装。

    可伸缩的媒体类型- ASF是设计用来表示可伸缩的媒体类型的"带宽"之间的依赖关系。ASF存储各个带宽就像一个单独的媒体流。媒体流之间的依赖关系存储在文件头部分,为客户机以一个独立于压缩的方式解释可伸缩的选项提供了丰富的信息流的优先级化- 现代的多媒体传输系统能够动态地调整以适应网络资源紧张的情况(如,带宽不足)。多媒体内容的制作者要能够根据流的优先级表达他们的参考信息,如最低保证音频流的传输。随着可伸缩媒体类型的出现,流的优先级的安排变得复杂起来,因为在制作的时候很难决定各媒体流的顺序。ASF允许内容制作者有效地表达他们的意见(有关媒体的优先级),甚至在可伸缩的媒体类型出现的情况下也可以.

    多语言- ASF设计为支持多语言。媒体流能够可选地指示所含媒体的语言。这个功能常用于音频和文本流。一个多语言ASF文件指的是包含不同语言版本的同一内容的一系列媒体流,其允许客户机在播放的过程中选择最合适的版本。

    目录信息- ASF提供可继续扩展的目录信息的功能,该功能的扩展性和灵活性都非常好。所有的目录信息都以无格式编码的形式存储在文件头部分,并且支持多语言,如果需要,目录信息既可预先定义(如,作者和标题),也可以是制作者自定义。目录信息功能既可以用于整个文件也可以用于单个媒体流。

    RealSystem的RealMedia文件格式

    RealNetworks公司的RealMedia包括RealAudio、RealVideo和RealFlash三类文件,其中RealAudio用来传输接近CD音质的音频数据,RealVideo用来传输不间断的视频数据,RealFlash则是RealNetworks公司与Macromedia公司新近联合推出的一种高压缩比的动画格式RealMedia文件格式的引入了,它使得RealSystem可以通过各种网络传送高质量的多媒体内容。第三方开发者可以通过RealNetworks公司提供的SDK将它们的媒体格式转换成RealMedia文件格式。

    QuickTime电影(Movie)文件格式

    Apple公司的QuickTime电影文件现已成为是数字媒体领域的工业标准。 QuickTime电影文件格式定义了存储数字媒体内容的标准方法,使用这种文件格式不仅可以存储单个的媒体内容(如视频帧或音频采样),而且能保存对该媒体作品的完整描述;QuickTime文件格式被设计用来适应为与数字化媒体一同工作需要存储的各种数据。因为这种文件格式能用来描述几乎所有的媒体结构,所以它是应用程序间(不管运行平台如何)交换数据的理想格式。QuickTime文件格式中媒体描述和媒体数据是分开存储的,媒体描述或元数据(meta-data)叫做电影(movie),包含轨道数目、视频压缩格式和时间信息。同时movie包含媒体数据存储区域的索引。媒体数据是所有的采样数据,如视频帧和音频采样,媒体数据可以与QuickTime movie存储在同一个文件中,也可以在一个单独的文件或者在几个文件中。

    展开全文
  • 流媒体

    千次阅读 2013-04-08 21:27:57
    一. 以Action Script 3.0(简称AS)开发Browser Player时,需要用NetStream,但现在NetStream.play只支持...而以Flash Media Server(简称FMS)或Red5作为流媒体服务器时,它们提供的是RTMP协议,且这两种流媒体服务器
  • 流媒体流媒体传输协议简介

    千次阅读 多人点赞 2019-06-01 22:26:10
    流媒体(streaming media):是指将一连串的媒体数据压缩后,经过网上分段发送数据,在网上即时传输影音以供观赏的一种技术与过程,此技术使得数据包得以像流水一样发送;如果不使用此技术,就必须在使用前下载整个...
  • [总结]RTMP流媒体技术零基础学习方法

    万次阅读 多人点赞 2013-11-18 00:10:34
    本文主要总结一些我在学习RTMP流媒体技术过程中积累的经验。也为后来学习RTMP流媒体技术的人们一个参考。本文力图从简到难,循序渐进的介绍RTMP流媒体技术的方方面面,先从应用说起,逐步深化剖析相关工程的源代码。...
  • 流媒体服务器原理和架构解析

    万次阅读 多人点赞 2016-07-25 09:54:09
    多媒体数据文件 一个完整的多媒体文件是由音频和视频两部分组成的,H264、Xvid等就是视频编码格式,MP3、AAC等就是音频编码格式,字幕文件只是附加文件。目前大部分的播放器产品对于H.264 + AAC的MP4编码格式支持...
  • 流媒体技术原理

    千次阅读 2013-01-06 16:13:45
     流媒体技术是一种专门用于网络多媒体信息传播和处理的新技术,该技术能够在网络上实现传播和播放同时进行的实时工作模式,相对于其他的一些音、视频网络传输和处理技术,流媒体比较成熟和使用,目前已经成为网上音...
  • 流媒体技术及其应用

    千次阅读 2014-09-28 13:11:39
    随着经济的发展和科学技术的进步,人类社会已进入了信息化的新时代。internet网的飞速发展,使人们对信息时代的网络经济有了全新的认识;每一次的创新,就有一次的飞跃;...而流媒体技术(streaming m
  • Python 流媒体播放器(基于VLC)

    万次阅读 多人点赞 2019-04-25 22:35:26
    文章目录环境准备VLC 安装安装python-vlc 绑定简单播放示例VLC 监听器视频加字幕VLC的选项参数设置音频可视化在Tkinter中...那有没有一种功能丰富全面又使用简单,而且还能支持流媒体播放的库呢?答案是有的。 VL...
  • 流媒体服务器总结

    千次阅读 2016-06-15 09:08:33
    最近一直研究流媒体服务器的搭建及使用,今天就简单整理下方便以后查阅。 一:企业级的流媒体平台框架:EasyDarwin EasyDarwin是在Apple开源流媒体服务器Darwin Streaming Server(v6.0.3)基础上进行...
  • WebRTC -- 流媒体基础概念

    万次阅读 2017-12-24 22:17:26
    流媒体协议 名称 推出机构 传输协议 客户端 RTSP+RTP IETF TCP+UDP VLC, WMP RTMP Adobe Inc. TCP Flash RTMFP Adobe Inc. UDP Flash MMS Microsoft Inc. TCP/UDP WMP HTTP ...
  • javaCV开发详解之2:推流器实现,推本地摄像头视频到流媒体服务器以及摄像头录制视频功能实现(基于javaCV-FFMPEG、javaCV-openCV) javaCV开发详解之3:收流器实现,录制流媒体服务器的rtsp/rtmp视频文件(基于javaCV...
  • 流媒体介绍

    千次阅读 2016-06-22 11:19:55
    一、 流媒体简介  1、流媒体的出现  长期以来,由于受到网路带宽的限制,互联网上的数据都是以文字、图片之类的静态内容为主,而那些音频、视频数据很难在网上发布,因为一般非压缩的广播级品质视频需要160...
  • 流媒体服务器实现

    万次阅读 2007-07-31 22:41:00
    1 引言 随着互联网的飞速发展,流媒体技术的应用越来越广泛,从网上广播、电影播放到远程教学以及在线的新闻网站等都用到了流媒体技术。但现有公开文献所报道 的大多是利用现有的流媒体服务器来搭建一个流媒体服务系统...
  • 流媒体服务器使用手册

    千次阅读 2018-11-15 10:25:20
    流媒体服务器使用手册     版本:V5.2   目 录 第1章 产品概述... 3 第2章 产品使用详解... 4 2.1 产品主要功能... 4 2.2 产品安装... 4 2.3.1 应用程序安装... 4 2.3.2 产品注册... 4 2.3.3 ...
  • LiveQing流媒体服务器软件,提供一站式的转码、点播、直播、时移回放服务,极大地简化了开发和集成的工作。 其中,点播功能主要包含:上传、转码、分发。直播功能,主要包含:直播、录像, 直播支持RTMP输入,RTMP/...
  • 流媒体技术概述

    2019-05-08 11:06:42
    一、流媒体定义 所谓流媒体,是指采用流式传输的方式在Iternet播放的媒体格式。流媒体又称流式媒体,是将普通多媒体,如音频、视频、动画等,经过特殊编码,使其成为在网络中使用流式传输的连续时基媒体,以适应在...
  • java实现流媒体播放

    热门讨论 2010-10-28 15:41:53
    Java实现流媒体实时播放,计算机网络的大作业,拿出来跟大家分享,不要怪分太多,都是精华,因为我也没分下其他资源了才上传的
  • 流媒体协议—HTTP
  • 38款 流媒体服务器开源软件

    千次阅读 2016-12-21 15:31:30
    Flash流媒体服务器 Red5 Red5是一个采用Java开发开源的Flash流媒体服务器。它支持:把音频(MP3)和视频(FLV)转换成播放流; 录制客户端播放流(只支持FLV);共享对象;现场直播流发布;远程调用。Red5...
  • 流媒体框架

    千次阅读 2017-06-01 22:29:20
    这里所说的框架,是指在底层实现的加载,缓冲,编码解码,拼接等等细节的整体方案。这种级别的功能,100%使用c实现,在android和Linux等系统进行make后build后,表现为各种so等文件。 对于应用层的开发工程师来说...
  • 需要选型一个流媒体服务器,故搜罗网上资料,整理出以下内容供参考 出处皆已标注链接 目录 流媒体协议 直播流媒体协议 理解RTMP、HttpFlv和HLS的正确姿势 流媒体文件支持格式 市面上主流的流媒体服务器归纳 ...
  • 流媒体传输协议介绍

    千次阅读 2016-07-01 18:39:12
    流媒体传输协议介绍一、RTSP协议介绍什么是rtsp? RTSP协议以客户服务器方式工作,,如:暂停/继续、后退、前进等。它是一个多媒体播放控制协议,用来使用户在播放从因特网下载的实时数据时能够进行控制, 因此 ...
  • 自适应流媒体传输(一)——DASH媒体内容的生成

    万次阅读 热门讨论 2016-01-02 23:01:07
    DASH(Dynamic Adaptive Streaming over HTTP)即自适应流媒体传输,典型的系统框图如下 简单概括来说,就是在服务器端提前存好同一内容的不同码率、不同分辨率的多个分片以及相应的描述文件MPD,客户端在播放时...

空空如也

1 2 3 4 5 ... 20
收藏数 668,528
精华内容 267,411
关键字:

媒体