精华内容
下载资源
问答
  • 新型视频编码标准H.264/AVC的扩展SVC(可扩展视频编码)技术为未来异构环境下的流媒体传输提供了一种新的解决方案。针对基于SVC的流媒体系统中的核心问题——质量自适应,提出了一种新的算法。该算法分为预缓存和...
  • 流媒体开发 网络层(socket或st):负责传输; 协议层(rtmp或hls):负责网络打包; 封装层(flv、ts):负责编解码数据的封装 编码层(h.264和aac):负责图像,音频压缩 帧:每帧代表一幅静止的图像 I帧:(关键帧)保留一副...

    思维导图

    在这里插入图片描述

    常用的名词:

    • 流媒体开发
      • 网络层(socket或st):负责传输;
      • 协议层(rtmp或hls):负责网络打包;
      • 封装层(flv、ts):负责编解码数据的封装
      • 编码层(h.264和aac):负责图像,音频压缩
    • 帧:每帧代表一幅静止的图像
      • I帧:(关键帧)保留一副完整的画面,解码时只需要本帧数据就可以完成(因为包含完整画面;
      • P帧:(差别帧)保留这一帧跟之前帧的差别,解码时需要用之前缓存的画面叠加上本帧定义的差别,生成最终画面。(P帧没有完整画面数据,只有与前一帧的画面差别的数据;
      • B帧:(双向差别帧)保留的是本帧与前后帧的差别,解码B帧,不仅要取得之前的缓存画面,还要解码之后的画面,通过前后画面的与本帧数据的叠加取得最终的画面.
    • GOP:(Group of Pictures)画面组,一个GOP就是一组连续的画面,每个画面都是一帧,一个GOP就是很多帧的集合
    • 码率:图片进行压缩后每秒显示的数据量
    • 帧率:每秒显示的图片数。影响画面流畅度,与画面流畅度成正比:帧率越大,画面越流畅;帧率越小,画面越有跳动感(由于人类眼睛的特殊生理结构,如果所看画面之帧率高于16的时候,就会认为是连贯的,此现象称之为视觉暂留。并且当帧速达到一定数值后,再增长的话,人眼也不容易察觉到有明显的流畅度提升了)。
    • 分辨率:(矩形)图片的长度和宽度,即图片的尺寸
    • 压缩前的每秒数据量:帧率X分辨率(单位应该是若干个字节)
      压缩比:压缩前的每秒数据量/码率 (对于同一个视频源并采用同一种视频编码算法,则压缩比越高,画面质量越差).
    • 视频文件格式:
      • 文件的后缀,比如.wmv,.mov,.mp4,.avi;
      • 主要用处,根据文件格式,系统会自动判断用什么软件打开,
      • 注意: 随意修改文件格式,对文件的本身不会造成太大的影响,比如把avi改成mp4,文件还是avi.
    • 视频封装格式
      • 一种储存视频信息的容器,流式封装可以有TS、FLV等,索引式的封装有MP4,MOV,AVI等;
      • 主要作用:一个视频文件往往会包含图像和音频,还有一些配置信息(如图像和音频的关联,如何解码它们等),这些内容需要按照一定的规则组织、封装起来.
      • 注意:会发现封装格式跟文件格式一样,因为一般视频文件格式的后缀名即采用相应的视频封装格式的名称, 所以视频文件格式就是视频封装格式
    • 视频封装格式和视频压缩编码标准
      • 就好像项目工程和编程语言,封装格式就是一个项目的工程,视频编码方式就是编程语言, 一个项目工程可以用不同语言开发

    音视频采集

    • 视频、音频硬件设备
      • CCD:图像传感器: 用于图像采集和处理的过程,把图像转换成数字信号。拾音器:声音传感器: 用于声音采集和处理的过程,把声音转换成电信号
      • 音频采样数据:一般都是PCM格式
        • 原理:主要通过设备将环境中的模拟信号采集成 PCM 编码的原始数据,然后编码压缩成 MP3 等格式的数据分发出去。常见的音频压缩格式有:MP3,AAC,HE-AAC,Opus,FLAC,Vorbis (Ogg),Speex 和 AMR等
        • 技术难点:延时敏感、卡顿敏感、噪声消除(Denoise)、回声消除(AEC)、静音检测(VAD)和各种混音算法等
      • 音频采集主要的几个参数:
        • 采样率(samplerate):采样就是把模拟信号数字化的过程,采样频率越高,记录这一段音频信号所用的数就越大,同时音频质量也就越高;
        • 位宽:每一个采样点都需要用一个数值来表示大小,这个数值的数据类型大小可以是:4bit,8bit,16bit,32bit等等.位数也越多就表示越精细,声音质量自然就越好,而数据量也会成倍增加.我们在音频采集过程中一般使用的都是8bit或者16bit的;
        • 声道数:由于音频的采集和播放是可以叠加的.因此,可以从多个音频采集声音,并分别输出到不同的扬声器,故声道数一般表示声音录制的音源数量或会放时相应的扬声器数量.声音1和2分别称为单声道和双声道,是比较常见的声道
        • 音频帧:音频跟视频很不一样.视频每一帧就是一张图像,音频数据是流式的,本身没有明确的一帧帧的概念.在实际应用中,为了音频算法处理/传输的方便,一般约定俗称取2.5ms~60ms为单位的数据量为一帧音频.这个时间被称为”采样时间”.其长度没有特别的标准,它是根据编解码器和具体应用的需求来决定的.
        • 小结:可以我们可以计算一下音频帧的大小.假设某音频信号是采样率为8KHZ,双通道,位宽为16bit,20ms一帧,则一帧音频数据的大小为:size=8000216bit*0.02s=640byte
      • 视频采样数据::一般都是YUV,或RGB格式,采集到的原始音视频的体积是非常大的,需要经过压缩技术处理来提高传输效率;
        • 原理:主要由摄像头等设备拍摄成 YUV 编码的原始数据,然后经过编码压缩成 H.264 等格式的数据分发出去。常见的视频封装格式有:MP4、3GP、AVI、MKV、WMV、MPG、VOB、FLV、SWF、MOV、RMVB 和 WebM 等
        • 技术难点:设备兼容性差、延时敏感、卡顿敏感以及各种对图像的处理操作如美颜和水印等.
        • 视频采集的主要几个参数
        • 图像传输格式:通过影像传输格式(common intermediate Format)是影讯会议(video conference)中常用的影像传输格式化;
        • 图像格式:通常采用YUV格式存储原始数据信息,其中包含8位表示黑白图像灰度值,以及可由RGB三种色彩组合后成的彩色图像;
        • 传输通道:正常情况下视频的拍摄只需1路通道,随着VR和AR技术的日渐成熟,为了拍摄一个完整的360视频,可能需要通过不同角度拍摄,然后通过多通道传输后合成
        • 分辨率:随着设备屏幕尺寸的日益增多,视频采集过程中原始视频分辨率起着越来越重要的作用,后续处理环节中使用的所有视频分辨率的定义都以原始视频分辨率为基础.视频采集卡能支持的对大点阵反应了其分辨率的性能.
        • 采样频率:采样频率卡反映了采集卡处理图像的速度和能力.再进行高度图像采集时,需要注意采集卡的采样频率是否满足要求.采样率越高,图像质量越高,同时保存这些图像信息的数据量也越大.
    • CCD与CMOS之间的区别:
      • CCD是一种半导体器件,能够把光学影像转化为数字信号,CCD上植入的微小光敏物质称作像素(Pixel),一块CCD上包含的像素数越多,其提供的画面分辨率也就越高.CCD上有许多排列整齐的电容,能感应光线,并将影像转变成数字信号.
      • CMOS是互补金属氧化物半导体,是电压控制的一种放大器件,是组成CMOS数字集成电路的基本单元.
      • 性能区别
        • ISO感光度:由于CMOS每个像素由四个晶体管与一个感光二极管构成,还包含了放大器与数模转换电路,过多的额外设备缩小了单一像素感光区域的表面积,因此相同像素下,同样的尺寸,CMOS的感光度会低于CCD
        • 分辨率:由于CMOS传感器的每个像素都比CCD传感器复杂,其像素尺寸很难达到CCD传感器的水平,因此,当我们比较相同尺寸的CCD与CMOS时,CCD传感器的分辨率通常会优于CMOS传感器
        • 噪点:由于CMOS每个感光二极管都需搭配一个放大器,如果以百万像素计,那么就需要百万个以上的放大器,而放大器属于模拟电路,很难让每个放大器所得到的结果保持一致,因此与只有一个放大器放在芯片边缘的CCD传感器相比,CMOS传感器的噪点就会增加很多,影响图像品质
        • 耗电量:CMOS传感器的图像采集方式为主动式,感光二极管所产生的电荷会直接由旁边的电晶体做放大输出;而CCD传感器为被动式采集,必须外加电压让每个像素中的电荷移动至传输通道。而这外加电压通常需要12~18V,因此CCD还必须有更精密的电源线路设计和耐压强度,高驱动电压使CCD的耗电量远高于CMOS。CMOS的耗电量仅为CCD的1/8到1/10

    视频处理

    • 视频处理原理
      • 因为视频最终也是通过GPU,一帧一帧渲染到屏幕上的,所以我们可以利用OpenGL ES,对视频帧进行各种加工,从而视频各种不同的效果
      • 作用:美颜算法,视频的模糊效果,水印,滤镜和可扩展处理都是在这个环节做的
    • 视频处理框架
      • GPUImage
        • GPUImage是一个基于OpenGL ES的一个强大的图像/视频处理框架,封装好了各种滤镜同时也可以编写自定义的滤镜,其本身内置了多达120多种常见的滤镜效果。
      • OpenGL
        • OpenGL(全写Open Graphics Library)是个定义了一个跨编程语言、跨平台的编程接口的规格,它用于三维图象(二维的亦可)。OpenGL是个专业的图形程序接口,是一个功能强大,调用方便的底层图形库。
      • OpenGL ES
        • OpenGL ES (OpenGL for Embedded Systems) 是 OpenGL三维图形 API 的子集,针对手机、PDA和游戏主机等嵌入式设备而设计。
    • 滤镜处理的原理
      • 就是把静态图片或者视频的每一帧进行图形变换再显示出来,它的本质就是像素点的坐标和颜色变化.

    音视频编码压缩

    • 视频编码框架
      • FFmpeg:是一个跨平台的开源视频框架,能实现对音频进行重采样,转换采样格式,对视频、音频和字幕流等编码/解码,对视频进行封装/解封装,进行视频的一些后期处理,视频图像缩放,颜色空间转换,滤镜功能等等
      • X264:把视频原数据YUV编码压缩成H.264格式
      • VideoToolbox:苹果自带的视频硬解码和硬编码API
      • AudioToolbox:苹果自带的音频硬解码和硬编码API
    • 软编码和硬编码的区别?
      • 软编码:使用CPU进行编码;实现直接、简单,参数调整方便,升级易,但CPU负载重,性能较硬编码低,低码率下质量通常比硬编码要好一点。编码比硬编码要复杂一些.
      • 硬编码:使用非CPU进行编码,如显卡GPU、专用的DSP、FPGA、ASIC芯片等;性能高,低码率下通常质量低于硬编码器,但部分产品在GPU硬件平台移植了优秀的软编码算法(如X264)的,质量基本等同于软编码
      • 主要区别:软编码可以在运行时确定,修改;而硬编码是不能够改变的
      • 目前的主流GPU加速平台:Intel、AMD、NVIDIA
      • 目前主流的GPU平台开发框架:
        • CUDA:NVIDIA的封闭编程框架,通过框架可以调用GPU计算资源;
        • AMD APP:AMD为自己的GPU提出的一套通用并行编程框架,标准开放,通过在CPU、GPU同时支持OpenCL框架,进行计算力融合
        • OpenCL:开放计算语言,为异构平台编写程序的该框架,异构平台可包含CPU、GPU以及其他计算处理器,目标是使相同的运算能支持不同平台硬件加速.
        • Inel QuickSync:集成于Intel显卡中的专用视频编解码模块
    • 视频编码技术
      • 视频压缩编码标准:使用MPEG/H.264对视频编码或者视频解码
      • 视频编码的意义:原始视频数据存储空间大,一个 1080P 的 7 s 视频需要 817 MB,原始视频数据传输占用带宽大,10 Mbps 的带宽传输上述 7 s 视频需要 11 分钟,而经过 H.264 编码压缩之后,视频大小只有 708 k ,10 Mbps 的带宽仅仅需要 500 ms ,可以满足实时传输的需求,所以从视频采集传感器采集来的原始视频势必要经过视频编码(将视频像素数据压缩成为视频码流,从而降低视频的数据量。如果视频不经过压缩编码的话,体积通常是非常大的,一部电影可能就要上百G的空间).
      • 基本原理(为什么巨大的原始视频可以编码成很小的视频呢?这其中的技术是什么呢):
        • 空间冗余:图像相邻像素之间有较强的相关性;
        • 时间冗余:视频序列的相邻图像之间内容相似;
        • 编码冗余:不同像素值出现的概率不同;
        • 视觉冗余:人的视觉系统对某些细节不敏感;
        • 知识冗余:规律性的结构可由先验知识和背景知识得到.
      • 视频压缩的三种方式:
        • MPEG:一种视频压缩方式,它采用了帧间压缩,仅存储连续帧之间有差别的地方,从而达到较大的压缩比.
        • H.264/AVC:一种视频压缩方式,采用事先预测和与MPEG中的P-B帧一样的帧预测方法压缩,它可以根据需要产生适合网络情况传输的视频流,还有更高的压缩比,有更好的图象质量。
          • 注意1:如果是从单个画面清晰度比较,MPEG有优势;从动作连贯性上的清晰度,H.264有优势;
          • 注意2:由于264的算法更加复杂,程序实现烦琐,运行它需要更多的处理器和内存资源。因此,运行264对系统要求是比较高的;
          • 注意3:由于264的实现更加灵活,它把一些实现留给了厂商自己去实现,虽然这样给实现带来了很多好处,但是不同产品之间互通成了很大的问题,造成了通过A公司的编码器编出的数据,必须通过A公司的解码器去解这样尴尬的事情.
        • H.265/HEVC:一种视频压缩方式,基于H.264,保留原来的某些技术,同时对一些相关的技术加以改进,以改善码流,编码质量、延时和算法复杂度之间的关系,达到最优化设置。
          • H.265 是一种更为高效的编码标准,能够在同等画质效果下将内容的体积压缩得更小,传输时更快更省带宽.因为这里使用到的是I帧,P帧,B帧技术.
          • 帧内(Intraframe)压缩:当压缩一帧图像时,仅考虑本帧的数据而不考虑相邻帧之间的冗余信息,帧内一般采用有损压缩算法
          • 帧间(Interframe)压缩:时间压缩(Temporal compression),它通过比较时间轴上不同帧之间的数据进行压缩。帧间压缩一般是无损的
          • muxing(合成):将视频流、音频流甚至是字幕流封装到一个文件中(容器格式(FLV,TS)),作为一个信号进行传输
    • 音频编码技术
      • AAC、mp3:这些属于音频编码技术,压缩音频用
    • 码率控制
      • 常看见视频播放软件中的1024,720、高清、标清和流畅等,指的就是各种码率.
    • 视频封装格式
      • 名次解释:封装可以理解为采用哪种货车去运输,也就是媒体的容器.所谓容器,就是把编码器生成的多媒体内容(视频,音频,字幕,章节信息等)混合封装在一起的标准。容器使得不同多媒体内容同步播放变得很简单,而容器的另一个作用就是为多媒体内容提供索引,也就是说如果没有容器存在的话一部影片你只能从一开始看到最后,不能拖动进度条,而且如果你不自己去手动另外载入音频就没有声音
      • TS 是 一种流媒体封装格式,流媒体封装有一个好处,就是不需要加载索引再播放,大大减少了首次载入的延迟。如果片子比较长,mp4文件的索引相当大,影响用户体验。
      • 为什么要用TS? 这是因为两个TS片段可以无缝拼接,播放器能连续播放
      • FLV:是一种流媒体封装格式,由于它形成的文件极小、加载速度极快,使得网络观看视频文件成为可能。因此,FLV格式成为了当今主流视频格式
    • 常见的封装格式
      • AVI 格式(后缀为 .avi)
        • 优点:图像质量好;
        • 缺点:体积过于庞大,压缩标准不统一.最普通的现象就是高版本的window媒体播放器播放不了采用早起编码编辑的AVI格式视频,而低版本的window媒体播放器播放不了最新编码编辑的AVI格式视频.
      • DV-AVI 格式(后缀为 .avi)
      • QuickTime File Format 格式(后缀为 .mov)
        • 优点:具有较高的压缩比和比较完善的视频清晰度等特点,并可以保存alpha通道.
      • MPEG 格式(文件后缀可以是 .mpg .mpeg .mpe .dat .vob .asf .3gp .mp4等);
      • WMV 格式(后缀为.wmv .asf);
        • 优点:本地或者网络回放,丰富的流间关系以及扩展性等;
        • 缺点:WMV格式需要在网站上进行播放,需要安装Windows Media Player;
      • Real Video 格式(后缀为 .rm .rmvb);
      • Flash Video 格式(后缀为 .flv);
      • Matroska 格式(后缀为 .mkv);
      • MPEG2-TS 格式 (后缀为 .ts)
        • 目前,我们在流媒体传输.尤其是在直播中主要采用的就是FLV和MPEG2-TS格式,分别用于RTMP/HTTP-FLV和HLS协议.

    推流

    • 数据传输框架
      • librtmp是用来传输RTMP协议格式的数据
    • 推送协议主要有三种:
      • RTSP(Real Time Streaming Protocol):实时流传送协议,是用来控制声音或影像的多媒体串流协议, 由Real Networks和Netscape共同提出的;
      • RTMP(Real Time Messaging Protocol):实时消息传送协议,是Adobe公司为Flash播放器和服务器之间音频、视频和数据传输 开发的开放协议;
      • HLS(HTTP Live Streaming):是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议;
    • 流媒体数据传输协议
    • RTMP是实时消息传输协议,Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议,因为是开放协议所以都可以使用了。
    • RTMP协议用于对象视频、音频的传输。这个协议建立在TCP协议或者轮询HTTP协议之上。
    • RTMP协议就像一个用来装数据包的容器,这些数据可以是FLV中的视音频数据。一个单一的连接可以通过不同的通道传输多路网络流,这些通道中的包都是按照固定大小的包传输的。chunk是消息包。
      • RTMP协议基于 TCP,是一种设计用来进行实时数据通信的网络协议,主要用来在 flash/AIR 平台和支持 RTMP 协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括 Adobe Media Server/Ultrant Media Server/red5 等.
      • 它有三种变种:
        • RTMP工作在TCP之上的明文协议,使用端口1935;
        • RTMPT封装在HTTP请求之中,可穿越防火墙;
        • RTMPS类似RTMPT,但使用的是HTTPS连接;
    • RTMP 是目前主流的流媒体传输协议,广泛用于直播领域,可以说市面上绝大多数的直播产品都采用了这个协议。
    • RTMP协议就像一个用来装数据包的容器,这些数据可以是AMF格式的数据,也可以是FLV中的视/音频数据。一个单一的连接可以通过不同的通道传输多路网络流。这些通道中的包都是按照固定大小的包传输的。
    • 推流的一个整体流程;
      • 建立tcp连接
      • 建立rtmp连接,以及发送各种控制指令
      • 获取原始视频数据和音频数据
      • 对原始视频数据和音频数据进行压缩编码(实现音视频数据的编码,视频编码成h264,音频编码成aac)
      • 对编码后的视频数据和音频数据进行打包
      • 发送打包后的音频和视频数据

    流媒体服务器处理

    • 常用服务器
    • CDN:(Content Delivery Network),即内容分发网络,将网站的内容发布到最接近用户的网络”边缘”,使用户可以就近取得所需的内容,解决 Internet网络拥挤的状况,提高用户访问网站的响应速度.
    • CDN工作原理:比如请求流媒体数据(http请求)
      • 当用户点击网站页面上的内容URL,经过本地DNS系统解析,DNS系统会最终将域名的解析权交给CNAME指向的CDN专用DNS服务器;
      • CDN的DNS服务器将CDN的全局负载均衡设备IP地址返回用户;
      • 用户向CDN的全局负载均衡设备发起内容URL访问请求;
      • CDN全局负载均衡设备根据用户IP地址,以及用户请求的内容URL,选择一台用户所属区域的区域负载均衡设备,告诉用户向这台设备发起请求;
      • 区域负载均衡设备会为用户选择一台合适的缓存服务器提供服务,选择的依据包括:根据用户IP地址,判断哪一台服务器距用户最近;根据用户所请求的URL中携带的内容名称,判断哪一台服务器上有用户所需内容;查询各个服务器当前的负载情况,判断哪一台服务器尚有服务能力。基于以上这些条件的综合分析之后,区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的IP地址;
      • 全局负载均衡设备把服务器的IP地址返回给用户;
      • 用户向缓存服务器发起请求,缓存服务器响应用户请求,将用户所需内容传送到用户终端。如果这台缓存服务器上并没有用户想要的内容,而区域均衡设备依然将它分配给了用户,那么这台服务器就要向它的上一级缓存服务器请求内容,直至追溯到网站的源服务器将内容拉到本地;
      • DNS服务器根据用户IP地址,将域名解析成相应节点的缓存服务器IP地址,实现用户就近访问。使用CDN服务的网站,只需将其域名解析权交给CDN的GSLB设备,将需要分发的内容注入CDN,就可以实现网站内容加速。
    • 在流媒体上面的工作原理:
      • 上传流媒体数据到服务器(源站)
      • 源站存储流媒体数据
      • 客户端播放流媒体,向CDN请求编码后的流媒体数据
      • CDN的服务器响应请求,若节点上没有该流媒体数据存在,则向源站继续请求流媒体数据;若节点上已经缓存了该视频文件, 则跳到第6步。
      • 源站响应CDN的请求,将流媒体分发到相应的CDN节点上
      • CDN将流媒体数据发送到客户端
    • 回源:当有用户访问某一个URL的时候,如果被解析到的那个CDN节点没有缓存响应的内容,或者是缓存已经到期, 就会回源站去获取搜索。如果没有人访问,那么CDN节点不会主动去源站拿.
    • 带宽:在固定的时间可传输的数据总量, 比如64位、800MHz的前端总线,它的数据传输率就 等于64bit×800MHz÷8(Byte)=6.4GB/s ;
    • 负载均衡:由多台服务器以对称的方式组成一个服务器集合,每台服务器都具有等价的地位,都可以单独对外提供服务而无须其他服务器的辅助.通过某种负载分担技术,将外部发送来的请求均匀分配到对称结构中的某一台服务器上,而接收到请求的服务器独立地回应客户的请求.均衡负载能够平均分配客户请求到服务器列阵,籍此提供快速获取重要数据,解决大量并发访问服务问题. 这种群集技术可以用最少的投资获得接近于大型主机的性能。
    • QoS(带宽管理):限制每一个组群的带宽,让有限的带宽发挥最大的效用

    拉流

    • 直播协议选择
      • 即时性要求较高或有互动需求的可以采用RTMP,RTSP;
      • 对于有回放或跨平台需求的,推荐使用HLS;
    • 直播协议对比 :
      在这里插入图片描述
      • HLS
        • 由Apple公司定义的用于实时流传输的协议,HLS基于HTTP协议实现,传输内容包括两部分,一是M3U8描述文件,二是TS媒体文件。可实现流媒体的直播和点播,主要应用在iOS系统。 HLS是以点播的技术方式来实现直播;
        • HLS是自适应码率流播,客户端会根据网络状况自动选择不同码率的视频流,条件允许的情况下使用高码率,网络繁忙的时候使用低码率,并且自动在二者间随意切换。这对移动设备网络状况不稳定的情况下保障流畅播放非常有帮助;
        • 实现方法:服务器端提供多码率视频流,并且在列表文件中注明,播放器根据播放进度和下载速度自动调整
        • HLS与RTMP对比:HLS主要是延时比较大,RTMP主要优势在于延时低
        • HLS协议的小切片方式会生成大量的文件,存储或处理这些文件会造成大量资源浪费
        • 相比使用RTSP协议的好处在于,一旦切分完成,之后的分发过程完全不需要额外使用任何专门软件,普通的网络服务器即可,大大降低了CDN边缘服务器的配置要求,可以使用任何现成的CDN,而一般服务器很少支持RTSP
        • HTTP-FLV是基于HTTP协议流式的传输媒体内容。相对于RTMP,HTTP更简单和广为人知,内容延迟同样可以做到1~3秒,打开速度更快,因为HTTP本身没有复杂的状态交互。所以从延迟角度来看,HTTP-FLV要优于RTMP
          • 特点:
          • 不是流媒体协议;
          • HTTP协议是共有协议,并有专门的机构进行维护;
          • HTTP协议没有特定的通道;
          • HTTP协议传输一般需要2~3个通道,命令和数据通道分离.
        • RTSP:实时流传输协议,定义了一对多应用程序如何有效地通过IP网络传送多媒体数据;
          • 特点:
          • 是流媒体协议;
          • RTSP协议是共有协议,并有专门的机构进行维护;
          • RTSP协议传输一般需要2~3个通道,命令和数据通道分离.
        • RTP:实时传输协议,RTP是建立在UDP协议上的,常与RTCP一起使用,其本身并没有提供按时发送机制或其它服务质量(QoS)保证,它依赖于低层服务去实现这一过程;
        • RTCP:RTP的配套协议,主要功能是为RTP所提供的服务质量(QoS)提供反馈,收集相关媒体连接的统计信息,例如传输字节数,传输分组数,丢失分组数,单向和双向网络延迟等等
        • RTMP协议:
          • 特点:
          • 是流媒体协议;
          • RTMP协议是Adobe的私有协议,未完全公开;
          • RTMP协议一般传输的是flv,f4v格式流;
          • RTMP一般在1个通道上传输命令和数据

    音视频解码

    • 解封装
      • demuxing(分离):从视频流、音频流,字幕流合成的文件(容器格式(FLV,TS))中, 分解出视频、音频或字幕,各自进行解码;
    • 音频编码框架
      • fdk_aac:音频编码解码框架,PCM音频数据和AAC音频数据互转;
    • 解码介绍
      • 硬解码:用GPU来解码,减少CPU运算
        • 优点:播放流畅、低功耗,解码速度快
        • 缺点:兼容不好
      • 软解码:用CPU来解码
        • 优点:兼容好
        • 缺点:加大CPU负担,耗电增加、没有硬解码流畅,解码速度相对慢

    播放

    • 一个典型的播放器可以分解成三部分UI、多媒体引擎和解码器:
      • 用户界面(UI):这是播放器最上层的部分.它通过三部分不同的功能特性定义了终端用户的观看体验:皮肤(播放器的外观设计),UI(所有可自定义的特性如播放列表和社交分享等)以及业务逻辑部分(特定的业务逻辑特性如广告,设备兼容性逻辑以及认证管理等)
      • 多媒体引擎:这里处理所有播放控制相关的逻辑,如描述文件的解析,视频片段的拉取,以及自适应码率规则的设定和切换等等
      • 解码器和DRM管理器:播放器最底层的部分是解码器和DRM管理器,这层的功能直接调用操作系统暴露出来的API,解码器的主要功能在于解码渲染视频内容,而DRM管理器则通过解密过程来控制是否有权播放
    • 用户界面(U)
      • UI层是播放器的最上层,它控制了你用户所能看到和交互的东西,同时也可以使用你自己的品牌来将其定制,为你的用户提供独特的用户体验。这一层最接近于我们说的前端开发部分。在UI内部,我们也包含了业务逻辑组件,这些组件构成了你播放体验的独特性,然终端用户没法直接和这部分功能进行交互.
    • UI用户的三大组件:
      • 皮肤—皮肤是对播放器视觉相关部分的统称:进度控条、按钮和动画图标等等
      • 逻辑—>U逻辑部分定义了播放过程中和用户交互方面所有可见的交互:播放列表、缩略图、播放频道的选择以及社交媒体分享等
      • 业务逻辑除了上面两部分可见的功能特性之外,还有一个不可见的部分,这部分构成了你业务的独特性:认证和支付、频道和播放列表的获取,以及广告等。这里也包含一些技术相关的东西,比如用于AB测试模块,以及和设备相关的配置这些配置用于在多种不同类型的设备之间选择多个不同的媒体引擎
    • 解码器和DRM管理器:
      • 解码器处理最底层播放相关的逻辑。它将不同封装格式的视频进行解包,并将其内容解码,然后将解码后的视频帧交给操作系统进行渲染,最终让终端用户看到
    展开全文
  • 摘要:媒体分发技术在保证IPTV业务的服务质量上具有相当关键的作用。CDN(内容分发网络)技术在Web业务上得到了较为广泛的应用,...关键词IPTV媒体流分发分层编码分段缓存1、概述自有电视业务以来,人们便不满足于仅被
    
    

    摘要:媒体分发技术在保证IPTV业务的服务质量上具有相当关键的作用。CDN(内容分发网络)技术在Web业务上得到了较为广泛的应用,但与传统的Web业务不同,IPTV需要分发的内容是数据量相当大的视频数据,采用传统的CDN技术不能完全满足IPTV业务的需要。本文介绍应用于IPTV视频流分发的代理缓存技术。
    关键词IPTV媒体流分发分层编码分段缓存

    1、概述

    自有电视业务以来,人们便不满足于仅被动地接收电视节目。用户一直希望能够按自己的意愿获得所喜爱的电视节目。这也不难理解为什么20世纪80年代,人们希望使用MTV;20世纪90年代人们希望使用视频点播业务;近几年,人们希望使用Internet协议电视(IPTV)业务。事实上目前所谈的IPTV在某种意义上讲是20世纪90年代视频点播业务(VOD)的一种继续。

    VOD出现之初。人们希望能够针对大众喜爱的电视节目内容提供时移电视,这样人们就可以在家里非常舒服地在方便的时候观看电影或电视节目。基本的思想是将内容存储在存储器中同时发展分发网络提供接入并投递这些视频内容。最初业务的推动者来自广播电视业务提供者和电影制片者。但遗憾的是由于在当时的技术条件下(当时期望的承载网络是基于ATM技术的宽带ISDN)所需要的基础设施费用相对于VOD业务的需求显得太高了一些。这样VOD在一段时间内发展缓慢,除了在一些局域网络上开放了一些VOD业务外,大多数的VOD停留在研究和试验层面。同时Web业务的出现,给人们带来了使用Web业务获得文本信息的喜悦。

    随着数字摄像机的出现、存储系统能力的增强、网络传输带宽的增加以及移动电话终端能力的增强,对网络视频信息的传输又一次成为人们关注的热点问题之一。与20世纪90年代的VOD的不同点在于网络视频的承载网络是IP网络,而用户的显示终端也扩展到包括电视终端、计算机、移动手机等。提供视频的方式也由广播电视的纯“推”的方式扩展到包括原有电视的“推”方式和VOD的“拉”方式。用户可以根据自己的意愿获取节目信息。也就是说IPTV将以类似于Web业务向用户提供文本信息一样向用户提供视频信息。

    虽然IPTV主要是向用户提供视频信息,但由于IPTV业务的业务形式和用户终端种类的增加,使得业务提供者不能仅采用单一的信息源同时向数量众多、终端能力各异的用户提供业务。本文将介绍IPTV业务中进行视频内容分发的一种技术——代理缓存技术。

    2、IPTV业务服务质量要求

    由于视频节目内容的信息量较大、若采用下载后播放的方式,用户在下载全部节目信息时需要花费较长的时间,为此在提供业务时不能使用下载后播放的方式而应采用类似于现有广播电视播放的方式,也就是说在下载的同时进行播放,从用户的角度看就是边下载边播放。IPTV业务主要提供媒体直播(广播)业务和媒体信息点播业务。对于直播方式要求视频流在播放时不能出现中断,同时播放时允许用户在多个节目中进行切换,切换时间要在相对短的时间范围内。而对于点播方式的业务要求用户可以找到所希望观看的节目同时可以对观看的节目进行适当的控制(包括快进、快退、暂停等),同时要求播放的视频节目信息流畅没有明显的中断。

    就目前视频编码技术的发展现状,实现用户在线实时播放视频节目信息所需的网络传输带宽通常在每秒兆比特数量级。IPTV业务主要以提供双向不对称的视频信息为主。用户和业务提供者之间主要是客户端/服务器方式进行通信。这样若多个用户同时观看存储在一个视频存储器中的视频节目信息对存储服务器的输入输出具有较高的要求,同时通信网络的带宽要求也较高。为此,对于IPTV业务通常采用类似目前CDN的技术将视频节目信息缓存到接近用户的边缘设施,以减小主视频存储服务器和通信网络的压力。但视频信息通常比文本信息的信息量大,若将全部的视频信息均缓存到边缘存储设备中会造成存储设施的浪费,同时由于用户采用具有不同能力的终端,要求业务提供者提供传输速率不同的视频信息。这样采用代理缓存技术成为解决Internet上媒体流传输的一个重要手段。

    3、代理缓存技术简介

    3.1媒体流代理缓存辅助的系统结构

    图1为采用代理方式进行媒体流投递的系统示意图。在该系统中,媒体流采用RTP/RTCP/RTSP进行投递。

    采用代理缓存的基本思想是用户(客户端)的控制信息和媒体投递信息在传输时采用两个不同的信道来进行。媒体流服务器根据控制信息的指令向用户(客户端)传递媒体信息。用户将其控制信息上传到媒体代理,若媒体代理的缓存器中存储有用户所要的媒体内容,则代理直接将其缓存器中存储的信息投递给用户(客户端)的缓存空间,缓存空间接收到媒体信息后将其传递给播放器用于播放。若缓存代理的缓存器中没有用户要求的信息,则发送指令给服务器请求传递相应的媒体信息。根据缓存代理的不同策略,服务器将媒体信息直接传输到代理的交换器或存储到缓存代理的缓存器中,由缓存器将媒体流信息再通过交换器传送给用户。

    图1采用代理方式进行媒体流投递的系统示意图

    图1采用代理方式进行媒体流投递的系统示意图

    3.2缓存代理技术

    从缓存代理技术本身来讲,是将媒体信息缓存在缓存代理处,然后将其传送给用户。但由于视频媒体信息本身信息量大的特点,若缓存代理作为服务器的备份,那么对缓存代理的要求将太高,势必增大业务提供者的成本。同时由于不同的节目内容用户的点击率并不相同,为此将所有的媒体内容采用相同的方式进行缓存没有必要。因而目前采用的代理缓存通常采用对热播的内容采用全部存储,而对点播量不大的媒体内容采用部分缓存的方式进行。但如何确定需要缓存什么、缓存多长时间的算法就成了研究者研究和讨论的一个问题。现有的缓存算法主要包括用于同质客户端的代理缓存和用于不同质客户端的代理缓存。

    3.3用于同质客户端的代理缓存

    目前大多数代理缓存技术适用于在代理之后具有相同或类似配置和能力的同质客户端。这样同一版本的媒体信息可以满足所有同质客户端对相同内容请求,同时对客户端连接到网络的带宽以及客户端的播放能力具有相同的要求。即使是这样,在代理缓存中存储一个节目内容的哪些部分以及如何管理代理缓存中已经存储的信息(如何放置以及如何替换所存的信息)仍然是具有挑战性的问题。不同算法会带来不同服务质量以及代理资源的不同消耗。本文主要介绍目前研究较多的4类代理缓存算法:可变时间间隔缓存、前缀缓存、分段缓存以及变速缓存。

    3.3.1可变时间间隔缓存

    可变时间间隔缓存算法采用缓存可变时间间隔的媒体信息以用于连续地接入流媒体。该算法的实现方式如下:当两个客户端在一段时间间隔内向同一个代理缓存器请求同一个媒体内容时,根据第一个客户端的请求,代理缓存器向媒体服务器请求发送媒体信息并将接收到的媒体信息发送给第一个请求者,同时将媒体信息存储在代理缓存器中,在第二个客户端的请求到来时,代理缓存器就可以将已经存储在缓存器中的媒体信息直接发送给第二个请求者,待媒体信息发送给第二个请求者后代理缓存器释放该媒体信息。这样媒体服务器只需要通过骨干网络将媒体信息传送一次便可以服务于两个客户端。从而节省了骨干网络带宽,同时减少了第二个请求者开始的等待时间,提高了服务质量。当多个客户端在一定的时间间隔内请求同一个媒体信息时,就可以将媒体信息从媒体服务器中请求一次然后存储在代理缓存器中,根据后续请求者的请求发送给相应的请求者,在媒体信息发送给最后一个请求者时释放媒体信息。这样仅在第一个客户端请求媒体信息时需要代理缓存器从媒体服务器中请求传送媒体信息,后续的客户端仅需从代理缓存器中获得媒体信息便可。根据请求同一媒体信息的第一个客户端到最后一个客户端请求的时间间隔不同,需要将媒体信息在代理缓存器中对媒体信息保留不同的时间间隔,当该间隔与整个节目的播放时间相同时,在代理缓存器中就保留了请求节目的全部信息。在一个节目热播期间通常需要在代理缓存器中存储热播节目的全部信息。

    3.3.2前缀缓存

    在上一种算法中,主要是减少对骨干网络的传输带宽的压力,同时提高后续请求者的初始播放速度。但第一个请求者的起始播放时间并没有减少,若在没有用户请求之前将每一个节目的开始部分存储在代理缓存器中,在第一个客户端请求媒体信息时也可以提高其起始速度,同时代理缓存器向每一个媒体服务器请求后续部分内容。这便是前缀缓存算法的基本思想。

    在采用前缀缓存算法时一个需要考虑的问题是最初在代理缓存器中应当缓存多长一段节目内容。考虑到,客户端需要平滑地播放媒体内容,代理缓存器中至少要存储从代理服务器到媒体服务器处接收到后续媒体信息的一段时间内足够客户端播放的信息。在代理缓存器的存储空间比较富裕的情况下,可以尽可能将前缀信息存储的相对长一些。

    3.3.3分段缓存

    前缀缓存算法主要解决起始响应速度问题,在其中隐含了一个媒体信息分段问题。前缀本身就意味着将媒体信息分成了不同的段信息。在代理缓存器从媒体服务器后续请求过程中也需要根据媒体信息的特征分段请求或发送。特别是针对点播类业务,客户端需要快进、快退等操作,这意味着需要在媒体信息中在分段处有标注信息。这也要求将媒体信息本身进行分段。

    分段缓存算法是目前学术界研究较多的一种算法,根据不同的用途分段缓存算法又分为指数级分段和“慢分段”,指数级分段是根据内容信息距起始点距离的不同将信息分成不同长度的段,距起始点越远段落的长度越大,这主要是用于代理缓存器快速调整所缓存的内容,在需要的时候可以丢弃大块的媒体信息内容。“慢分段”其基本思想是尽可能晚地对媒体信息进行分段,而要等到收集到了尽可能多的统计信息再对媒体信息进行分段,这样可以最好地降低对带宽的要求,提高服务质量。

    分段缓存的最大好处在于可以进行可变比特率传输,为此也有提出根据内容提供者的意见将内容信息中最为精彩的片段取出来进行分段,并在客户端最初观看内容时为其提供这些精彩片段,然后由用户确定是否继续观看所选择的内容或者是直接跳转到其认为最为好看的部分内容。

    3.3.4分速率缓存

    上面三种算法均是根据时间顺序进行缓存以减少对网络带宽的压力,没有考虑到媒体信息编码后不同时间上信息量的不同从而带来的网络传输带宽需求的变化。分速率缓存算法的基本思想是,将从时间轴上看不同时间段上不同速率的信息,在媒体服务器中存储等速率的部分信息,而在代理缓存器中存储变化速率的部分信息。这样在代理缓存器与媒体服务器之间将采用等速率传输媒体信息,代理缓存器将接收到的等速媒体信息与已经缓存在代理缓存器中变速率部分的媒体信息组合起来发送给客户端,以满足播放器连续播放的要求。

    3.4用于不同质客户端的代理缓存

    3.3中所介绍的代理缓存主要适用于可以接收相同速率并可以使用相同格式的客户端。IPTV业务可以向采用不同的接入网络接入并具有不同设备配置的客户端提供业务。在这种情况下,为满足不同能力客户端的需要,媒体服务器需要存储采用不同格式适用于网络速率的同一内容的多种备份,这样耗费了大量的存储和网络资源。为解决该问题,分层编码方式应运而生。这种算法是将媒体信息按层进行编码,将具有重要信息的层编码存储在代理缓存器中,将其他层信息存储在媒体服务器中。对于要求速率低的客户端,代理缓存器直接将所存储的信息发送过去就可以满足其需要,而对于要求速率高的客户端,代理缓存器可以先将所存储的信息发送到客户端,同时向媒体服务器请求其他层的信息再转发给客户端,以满足客户端对信息速率和信息格式的要求。目前通常是将媒体信息分为2~3层。最优的分层方式还在研究之中。

    通常可适用于速率范围较大的编码速率,如MPEG-4多采用分层编码算法。其最大的优点就是对传输速率和显示格式有不同要求的客户端,采用不同层信息的不同组合,从而节省存储空间和传输带宽。

    3.5重叠网络上的代理缓存

    目前的Internet运营商多苦于类似BT一类的视频下载软件在网络上的使用。多对一的视频信息的传输消耗了网络的大量资源,造成了网络拥塞。据有关统计,目前BT下载信息在Internet上的全部信息量中占有很大的比例。从实现机理上来讲采用peertopeer的方式进行视频信息传递也是一种代理缓存,在peertopeer环境中,每一个客户端即是服务器也是客户端。而从代理缓存的角度,由于客户端所存储的信息是来自于同一个媒体服务器,在这种意义上讲每一个客户端起到代理缓存器的作用。

    peertopeer环境通常是一个松耦合的环境,每一个客户端均可能在不通知其他客户端的情况下离开或者禁止其他客户端访问。这样势必会影响业务的服务质量,若是将peertopeer配置在第二层代理缓存,而第一层代理缓存采用由业务提供商配置固定的代理缓存器来完成,这样一方面可以提高业务的服务质量,一方面可以节省业务提供者代理缓存器的资源。

    4、结束语

    IPTV业务是目前业界的一个热点问题,虽然IP网络目前的传输带宽已经达到一定的程度并且有能力传输像视频信息一类对传输带宽要求较高的信息。但是在提供以单播形式为主的点播类视频业务时如何投递视频信息以满足用户的需要仍然是一个很大的挑战。代理缓存技术在Web业务采用的CDN上已经有很多的应用。但与文本信息相比,点播类视频业务本身信息量大、传输带宽要求高、交互性要求高的特点不能将用于Web业务的代理缓存技术简单地应用于视频点播业务。而需要采用特定的算法来实现节省存储器和传输资源的目的。本文中简单介绍了目前正在使用或处于研究阶段的代理缓存算法。这些算法通常是针对某种特定场合而设计的,它们之间没有排斥性,通常具有互补性,在具体使用中可以同时采用,也可以针对不同的应用环境采用部分算法。目前已经商用的代理缓存通常采用相对简单的算法以满足实现简单的目的。代理缓存算法仍处于发展之中,这些技术的顺利进展并在IPTV业务中应用将有利于IPTV业务的健康发展。

     

    转自http://www.sansky.net/article/2007-08-10-iptv-cdn.html

    展开全文
  • 视频流媒体中视频数据的传输占据了绝大部分的带宽,如何提升编码效率、减小带宽使用、提升画面质量,成为音视频开发者努力的重点。随着互联网、流媒体技术的发展,兼容支持H.264、H.265编码器(可减少计算的复杂性、...

    视频流媒体中视频数据的传输占据了绝大部分的带宽,如何提升编码效率、减小带宽使用、提升画面质量,成为音视频开发者努力的重点。随着互联网、流媒体技术的发展,兼容支持H.264、H.265编码器(可减少计算的复杂性、提高压缩率,并降低编码时间)已经成为迫在眉睫的事。

    EasyRTMP工作流程.png

    EasyRTMP是结合了多种音视频缓存及网络技术的一个rtmp直播推流端,包括:圆形缓冲区(circular buffer)、智能丢帧、自动重连、rtmp协议等等多种技术,能够非常有效地适应各种平台(Windows、Linux、ARM、Android、iOS),各种网络环境(有线、wifi、4G),以及各种情况下的直播恢复(服务器重启、网络重启、硬件设备重启)。

    EasyRTMP-Android启动软编码

    提出问题
    EasyRTMP-Android 如何开启软编码?

    分析问题
    最近EasyRTMP-Android新增了软编码的功能,

    解决问题
    1、在设置界面,提供了使用软编码的选择框:

    3.png

    可以设置是否使用软编码:

    SPUtil.setswCodec(this, isChecked)
    

    2、启动视频软编码器SWConsumer,本质就是X264Encoder。X264Encoder加载了libx264enc.so库,主要方法是

        /**
         * 创建编码器
         *
         * @param w       要编码的视频的宽度
         * @param h       要编码的视频的高度
         * @param bitrate 要编码的码率
         */
        public void create(int w, int h, int frameRate, int bitrate) {
            long[] handle = new long[1];
            create(w, h, frameRate, bitrate, handle);
            mHandle = handle[0];
        }
    
        /**
         * 编码
         *
         * @param yv12      yv12格式的视频数据(数据长度应该为w*h*1.5)
         * @param offset    视频数据的偏移(即在yv12里的起始位)
         * @param out       编码后的数据。
         * @param outOffset 编码后的视频数据的偏移(即在out里的起始位)
         * @param outLen    outLen[0]为编码后的视频数据的长度
         * @param keyFrame  keyFrame[0]为编码后的视频帧的关键帧标识
         * @return returns negative on error, zero if no NAL units returned.
         */
        public int encode(byte[] yv12, int offset, byte[] out, int outOffset, int[] outLen, byte[] keyFrame) {
            return encode(mHandle, yv12, offset, out, outOffset, outLen, keyFrame);
        }
    
        /**
         * 关闭编码器
         */
        public void close() {
            close(mHandle);
        }
    展开全文
  • 音视频流媒体硬解码是指不使用CPU进行编码,使用显卡GPU,专用的DSP、FPGA、ASIC芯片等硬件进行编码编码框架Video ToolBox和AudioToolbox。 EasyRTMP是结合了多种音视频缓存网络技术的一个rtmp直播推流端,包括...

    音视频流媒体硬解码是指不使用CPU进行编码,使用显卡GPU,专用的DSP、FPGA、ASIC芯片等硬件进行编码。编码框架Video ToolBox和AudioToolbox。

    EasyRTMP是结合了多种音视频缓存及网络技术的一个rtmp直播推流端,包括:圆形缓冲区(circular buffer)、智能丢帧、自动重连、rtmp协议等等多种技术,能够非常有效地适应各种平台(Windows、Linux、ARM、Android、iOS),各种网络环境(有线、wifi、4G),以及各种情况下的直播恢复(服务器重启、网络重启、硬件设备重启)。

     

    EasyRTMP-Android 音频采集

    EasyRTMP-Android音频采集是基于AudioRecord实现的。

    1、权限申请

    <uses-permission android:name="android.permission.RECORD_AUDIO"/>
    

    2、初始化

    /*
        * 1、配置参数,初始化AudioRecord构造函数
        * audioSource:音频采集的输入源,DEFAULT(默认),VOICE_RECOGNITION(用于语音识别,等同于DEFAULT),MIC(由手机麦克风输入),VOICE_COMMUNICATION(用于VoIP应用)等等
        * sampleRateInHz:采样率,注意,目前44.1kHz是唯一可以保证兼容所有Android手机的采样率。
        * channelConfig:通道数的配置,CHANNEL_IN_MONO(单通道),CHANNEL_IN_STEREO(双通道)
        * audioFormat:配置“数据位宽”的,ENCODING_PCM_16BIT(16bit),ENCODING_PCM_8BIT(8bit)
        * bufferSizeInBytes:配置的是 AudioRecord 内部的音频缓冲区的大小,该缓冲区的值不能低于一帧“音频帧”(Frame)的大小
    * */
    mAudioRecord = new AudioRecord(MediaRecorder.AudioSource.MIC,
                                samplingRate,
                                AudioFormat.CHANNEL_IN_MONO,
                                AudioFormat.ENCODING_PCM_16BIT,
                                bufferSize);
    

    3、开始采集

    mAudioRecord.startRecording();
    

    4、读取采集到的声音数据

    /*
        * 不断的读取采集到的声音数据,放进编码器的输入缓存inputBuffers中 进行编码
        *   audioBuffer 存储写入音频录制数据的缓冲区。
        *   sizeInBytes 请求的最大字节数。
        * public int read (ByteBuffer audioBuffer, int sizeInBytes)
        *  */
    len = mAudioRecord.read(inputBuffers[bufferIndex], BUFFER_SIZE);
    

    5、停止采集,释放资源。

    if (mAudioRecord != null) {
        mAudioRecord.stop();
        mAudioRecord.release();
        mAudioRecord = null;
    }
    

    以上就是EasyRTMP-Android 音频采集流程。

    展开全文
  • 流媒体服务器端 TCP 协议栈范畴降低延时 GOP 缓存产生延时 数据队列长度、转发时间间隔等参数产生延时 拉流端 当拉流端网络产生阻塞,若当拉流端网络恢复正常后,服务器缓存了 3 秒数据,则播放必然会有 3 秒的...
  • 音视频流媒体硬解码是指不使用CPU进行编码,使用显卡GPU,专用的DSP、FPGA、ASIC芯片等硬件进行编码编码框架Video ToolBox和AudioToolbox。 EasyRTMP是结合了多种音视频缓存网络技术的一个rtmp直播推流端,包括...
  • 音视频流媒体硬解码是指不使用CPU进行编码,使用显卡GPU,专用的DSP、FPGA、ASIC芯片等硬件进行编码编码框架Video ToolBox和AudioToolbox。 EasyRTMP是结合了多种音视频缓存网络技术的一个rtmp直播推流端,包括...
  • 10.5 流媒体技术在视频监控中的应用 320 10.5.1 视频监控系统需求分析 320 10.5.2 流媒体概念 321 10.5.3 流媒体在视频监控中的 应用 322 10.6 sip协议介绍 324 10.6.1 信道分离技术 324 10.6.2 sip...
  • 共3卷,卷1,卷2,3不需资源...10.5 流媒体技术在视频监控中的应用 320 10.5.1 视频监控系统需求分析 320 10.5.2 流媒体概念 321 10.5.3 流媒体在视频监控中的 应用 322 10.6 sip协议介绍 324 10.6.1 信道...
  • 10.5 流媒体技术在视频监控中的应用 320 10.5.1 视频监控系统需求分析 320 10.5.2 流媒体概念 321 10.5.3 流媒体在视频监控中的 应用 322 10.6 sip协议介绍 324 10.6.1 信道分离技术 324 10.6.2 sip架构下的...
  • 问题3-6:为什么计算机进行通信时发送缓存和接收缓存总是需要的? 问题3-7:以太网使用载波监听多点接入碰撞检测协议CSMA/CD。频分复用FDM才使用载波。以太网有没有使用频分复用? 问题3-8:在以太网中,不同的传输...
  • 而计算机网络所讨论的透明传输,是指比特看不见电路的存在。这样看来,两种“透明”的意思很不一样。应当怎样理解? 问题1-25:怎样才能知道哪些RFC文档已经成为因特网的正式标准(草案或建议标准)? 问题1-26:...
  • 2.3.13 NDIS提供的媒体相关宏 46 第三章 NIC微端口驱动程序入口点和初始化 47 3.1 NDIS微端口驱动程序入口函数 47 3.1.1 初始化包裹 47 3.1.2 注册微端口 48 3.1.2.1 指定NDIS版本号 48 3.1.2.2 注册MiniportXxx函数...
  • 网络驱动程序设计(NDIS)

    热门讨论 2009-11-22 21:24:00
    2.3.13 NDIS提供的媒体相关宏 46 第三章 NIC微端口驱动程序入口点和初始化 47 3.1 NDIS微端口驱动程序入口函数 47 3.1.1 初始化包裹 47 3.1.2 注册微端口 48 3.1.2.1 指定NDIS版本号 48 3.1.2.2 注册MiniportXxx函数...
  • (2)给其服务用户(数据链路层)在一条物理的传输媒体上传送和接收比特(一般为串行按顺序传输的比特)的能力,为此,物理层应该解决物理连接的建立、维持和释放问题。 (3)在两个相邻系统之间唯一地标识数据...
  • 5.3.2 移动流媒体编码的一般要求 12 5.4 HMS流媒体服务器的流媒体文件转换 13 6 调测操作 13 6.1 HMS运行的Linux与PC的目录文件共享 13 6.2 WEB与流媒体服务器的设置 14 6.2.1 流媒体服务器网络设置。 14 6.2.2 在...
  • VOD学习之TS详解

    千次阅读 2013-06-11 18:33:41
    1,有关机顶盒音视频性能的影响因素? 分层,1流媒体传输层,2流媒体编解码层,3解码器...其他因素有,当流媒体编码的速率抖动过大,视频服务器输出的码流抖动过大,网络传输丢包或抖动过大等等,都会使机顶盒收到的码
  • 最近在做流媒体,把采集到的图片处理后推送到rtmp上去,用vlc播放,发现总是有3-4s的延迟。 延迟影响因素 编码器:不同的编码器(免费或开源的),延迟也是不同的。 流媒体服务器:SRS2 流协议:比如:rtmp是...
  • 这篇文章从编码、传输、缓存等方面入手,分析了延迟产生的原因。 何时使用 TypeScript - 使用场景全解 距离微软 2012年10 月首次发布 TypeScript 0.8 版本已将近 8 年,越多的公司和团队开始尝试.
  • 跨平台开源流媒体服务端 Node-Media-Server 基于Node.JS开发, 跨平台/高性能, 支持RTMP协议推流,RTMP/HTTP-FLV/WebSocket-FLV播放, 内置推流鉴权/播放防盗链/GOP缓存急速秒开. 高级版 硬件加速的视频编解码器 ...
  • 面试关键字

    2012-02-21 09:12:16
    对于流媒体式则可以定位到任意帧。 wmv 视频,也是适应于网络传输的格式。有恒定码率 和 可变码率的方式。可变码率即可以对视频 的不同部分采用不同的码率进行压缩编码。 mpeg4 不适合网络传输。 ...
  • RFC1658 字符设备使用SMIv2管理对象的定义 RFC1661_点对点协议(PPP) RFC1671 向IPng 过渡和其他考虑的白皮书 RFC1690 Internet工程与计划组(IEPG)介绍 RFC1691 康奈尔大学数字图书馆文档体系结构 RFC1696 用...
  • 52、手机网络相关 53、Notification相关 54、对象相关 55、提取颜色的帮助类 56、目录路径相关 57、权限相关 58、轮询相关工具类 59、判断先决条件 60、进程相关 61、随机数相关 62、反射相关 63、正则表达式相关 64...
  • RFC中文文档-txt

    2009-09-11 14:56:56
    RFC1658 字符设备使用SMIv2管理对象的定义 RFC1661 点对点协议(PPP) RFC1671 向IPng 过渡和其他考虑的白皮书 RFC1690 Internet工程与计划组(IEPG)介绍 RFC1691 康奈尔大学数字图书馆文档体系结构 RFC1696 用SMIv...

空空如也

空空如也

1 2 3 4 5
收藏数 83
精华内容 33
关键字:

网络编码缓存流媒体