对于720P分辨率,深度为8的一幅图片的数据量为:1280*720*8(位),如果视频帧率为15,那一秒钟的数据量为:
视频编解码硬件方案最早是在嵌入式领域中广泛存在,如采用DSP,FPGA,ASIC等,用来弥补嵌入式系统CPU等资源能力不足问题,但随着视频分辨率越来越高(从CIF经历720P,1080P发展到4K,8K),编码算法越来越复杂(从mpeg2经历h264,发展到h265),PC的软件规模也越来越庞大,视频应用也越来也丰富,单独靠CPU来编解码已经显得勉为其难,一种集成在显卡中gpu用来参与编解码工作已经成为主流。
在刚提出4K视频的时候,大多数人都觉得没有必要,4K的出现,意味着更高的硬件规格和传输要求,1080P看的很爽、很清晰,完全满足了日常的需求。随着电视的尺寸越来越大,原本1080P成像已经无法满足人们对于细节的极致追求,4K视频不仅成像更细腻,在细节处理上优势也非常明显,颜色也更亮丽、饱满,逼真,给人身临其境的感觉。4K视频具有高分辨率、宽色域、高动态范围等优势,随着5G技术和H.265(HEVC)编码标准的出炉,4K视频直播迎来了曙光。
相信很多人和我一样,刚开始的时候都会很好奇,为什么h264可以实现这么强大的压缩比,要知道,1张1080p的YUV420就是3MB,想实现1秒钟30帧,千兆网就基本跑满了,这也太可怕了,基本上只有条件很好的局域网才能达到这个水平。但是h264的出现把这个数据量降到了百分之一,2个数量级,这实在太可怕了,技术的发展真的是强大。
AVCodecContext 结构表示程序运行的当前 Codec 使用的上下文,着重于所有 Codec 共有的属性(并且是在程序运行时才能确定其值)和关联其他结构的字段。
ffmpeg -i mp4_sample.mp4 -vcodec copy -an -bsf:v h264_mp4toannexb raw.h264
『音视频技术开发周刊』由LiveVideoStack团队出品,专注在音视频技术领域,纵览相关技术领域的干货和新闻投稿,每周一期。点击『阅读原文』,浏览第92期内容,祝您阅读愉快。 架构 从通信到AI FreeSWITCH与WebRTC FreeSWITCH是一个开源的软交换平台,具有模块化结构,支持包括WebRTC在内的多种互通互联。本文来自FreeSWITCH 中文社区创始人杜金房在LiveVideoStack线上交流分享中的演讲,详细介绍了FreeSWITCH的功能特性、架构以及现状。 如何利用免版
前一篇《webrtc方案漫谈》我们分析了webrtc的方案特点,根据实际的应用场景我们需要对webrtc native代码进行定制开发,下面对webrtc常规需求进行定制。
这几篇文章内容联系紧密,但放在一篇文章里内容太长,遂作拆分。章节号不作调整。基于FFmpeg 4.1版本。
本文主要介绍了如何在移动端GPU上对视频进行高效的编码与解码,通过对比多种编码方式、使用GPU对视频进行硬件加速、利用GPU对视频进行实时处理、以及对视频进行高效压缩与解码,最终实现了在移动端GPU上对视频进行高效编码与解码的解决方案。
我们在做Windows平台Unity播放RTMP或RTSP的时候,遇到这样的问题,比如展会、安防监控等场景下,需要同时播放多路RTMP或RTSP流,这样对设备性能,提出来更高的要求。
H.264从1999年开始,到2003年形成草案,最后在2007年定稿有待核实。在ITU的标准⾥称为H.264,在MPEG的标准⾥是MPEG-4的⼀个组成部分–MPEG-4 Part 10,⼜叫Advanced Video Codec,因此常常称为MPEG-4 AVC或直接叫AVC。
本文基于之前的Demo添加了FFmpeg使用MediaCodec来硬解码的方式,包括解码出buffer再利用OpenGL进行渲染上屏和直接解码到Surface然后上屏两种方式
3.1 FFmpeg本身支持一些编码、封装与协议,但是支持的依然有限,有些是因为licence,有些是因为相对来说比较大,FFmpeg所做的是提供一套基础的框架,而这些编码、封装与协议可以作为一个FFmpeg的模块挂在FFmpeg中,这些模块以第三方的外部库的方式提供支持,可以通过FFmpeg的源码的configure进行查看FFmpeg默认支持的编码、封装与协议的支持,不支持的可以再configure –help的时候查看所支持的第三方外部库,可以通过对应的参数选项进行支持:
实现了浏览器 MSE (Media Source Extensions) 播放相机 RTSP (Real Time Streaming Protocol) 流。动手体验一下咯~
在线直播可以说从去年开始变成了一个火爆的创业领域,一下子出来了很多做视频直播的公司。但说实话这方面的技术书籍实在是非常的少,网上的资料也很零散,所以我决定写一些列介绍视频技术的文章。今天这篇文章先对视频技术中的基础概念做一些简单的总结。
我们在做Windows平台RTMP推送或轻量级RTSP服务模块的时候,遇到这样的问题,有些超高清场景(4K甚至更高分辨率)或高帧率场景(50帧+)的编码,比如地铁安检机数据分析检测,设备性能一般的话,软编码很容易出现瓶颈,这个时候就需要硬编。基于此,我们前几年发布了基于NVIDIA的硬编。
16年壮观的直播百团大战相信大家历历在目,至19年初所剩无几的直播寡头,来去如风的直播战场,离不开背后强大的直播技术支撑,本文通过直播基础技术介绍、剖析企鹅电竞直播构架、关键技术、常见问题排查、带领大家了解直播技术细节。 直播基础技术扫盲 分辨率 分辨率是度量位图图像内数据量多少的一个参数。通常表示成每英寸像素(Pixel per inch, ppi)和每英寸点(Dot per inch, dpi),包含的数据越多,图形文件的长度就越大,也能表现更丰富的细节。但更大的文件需要耗用更多的计算机资源,更多的内
在一个嵌入式设备中,视频相关业务流程如下,DSP采集编码后,生成H264数据,然后对H264数据分别进行MP4、RTP、PS封装,封装后形成的数据进入对应的缓存队列。缓存队列是DSP和APP共享的,DSP写入,APP读取。
我们在对接开发者的时候,遇到这样的诉求:除了正常的RTMP、RTSP直播播放外,有些硬件设备输出编码后(H.264/H.265)的数据,比如无人机或类似硬件产品,回调出来的H.264/H.265数据,除了正常转推到RTMP、轻量级RTSP服务或GB28181外,还需要本地预览甚至重新对数据做二次处理,基于这样的场景诉求,我们开发了外部编码后数据实时预览播放模块。
Android的视频相关的开发,大概一直是整个Android生态,以及Android API中,最为分裂以及兼容性问题最为突出的一部分。摄像头,以及视频编码相关的API,Google一直对这方面的控制力非常差,导致不同厂商对这两个API的实现有不少差异,而且从API的设计来看,一直以来优化也相当有限,甚至有人认为这是“Android上最难用的API之一” 以微信为例,我们录制一个540p的mp4文件,对于Android来说,大体上是遵循这么一个流程: ---- ---- 大体上就是从摄像头输出的YUV帧
6.支持S3C6410 H264、H263、VC-1/WMV3、Mpeg4 480P 30fps播放
/* * Video Acceleration (shared data between FFmpeg and the video player) * HW decode acceleration for MPEG-4, H.264, H263 and VC-1 * Using Samsung Multi-Format Codec API * * Copyright(C) 2012 TuYuanDong * author: tuyaundong * email: tuyuandong@gmail.com
首先,我们来看看I帧的PS流格式,这里需要注意的是SPS、PPS之前要加上PES头部。如下图所示,其中绿色部分就是我们拿到的H.264裸流数据,须将它拆分成三段并在前面加上PES头部。这一点在GB28181标准中没有细说,需要通过分析海康IPC流才能看出。
FFmpeg是音视频领域很有名的一个库, 这里从两方面介绍, 一方面根据FFMPEG的命令行工具介绍, 介绍这些命令行工具的使用方法, 满足一般用户要求. 还有一方面从组件/库的划分来介绍, 介绍FFMPEG是有哪些组件和库组成, 每一个库的作用, 便于后续的自定义开发.
今天为大家介绍一下音视频直播技术中的视频编码。在移动端通过Camera采集到视频数据后,我们不会直接将它发送出去。因为采集后的视频数据量非常大,比如 1280x720 分辨率的一帧数据,就有可能达到6M大小(码率越高,图像越清晰)。这6M数据如果送到网上传输,会给网络带来非常大的负担。
PS、TS、FLV这三种简单封装格式。里面包含了对国标流的PS流处理方法,同时解析了HLS的TS文件格式以及常用的FLV文件,更详细内容可以看以前的几篇文章:
先从opencv(2.4.10版本)采集回来摄像头的图像,是一帧一帧的 每一帧图像是一个矩阵,opencv中的mat 数据结构。
因为工作原因,接触编解码也有一段时间了。AVC,HEVC,大大小小的功能都也接触了一些,关于编解码的原理的书和文章自己一直在看。从入门到略懂,感觉有些零零碎碎,或不完整,似乎串不成体系。有些小功能,知道是知道,并不知道它的意义和作用,时间一长也会慢慢忘记。 反思了一下,或许很多东西,还是需要自己动手做一遍,会理解的更深更透彻一些,就像费曼学习法,你能讲出来,才说明懂了,这个也一样,你能把功能实现出来,才说明你真的明白了里面的流程和逻辑。于是乎,在今年过年期间,突然萌生出了写一个解码器的想法,而且一萌生就一直压不住了,一直想赶快动键盘写起来。 其实目前市面上开源好用的解码器有不少,像ffmpeg,x264等等。自己这个工程,应该就是单纯的一个学习工程吧,估计最后再怎么优化也达不到这些大名鼎鼎的工程的效果和功能,但是那又怎么样呢,过程和经历也很棒,不是吗? 刚开始的时候是想写过一个编码器的,思考了一下之后很快就放弃了,我目前的想法只是想熟悉协议,并不是侧重于编码算法,相比之下,编写一个解码器所需要的的知识正是我所需要的。 这就成了这一系列文章的的起因了,算是自己一边写代码,一边写总结吧。 虽说是从“零”开始,但是编解码的基础知识还是要有一些储备的,我会在每一章里对解码所涉及到的知识点做一个介绍和讲解,但是太零碎的,就不会一一说明了。如果知识点太大,可能会单独写一篇来总结。
Android端的视频相关的开发,大概一直是整个Android生态,以及Android API中,最为分裂以及兼容性问题最为突出的一部分。摄像头,以及视频编码相关的API,Google一直对这方面的控制力非常差,导致不同厂商对这两个API的实现有不少差异,而且从API的设计来看,一直以来优化也相当有限,甚至有人认为这是“Android上最难用的API之一”
本例实现,将输入文件中的视频流和音频流分离出来,保存为单独的文件,所保存的文件是不含封装格式的裸流文件。
在GB28181协议中,在实时音视频传输过程中,使用INVITE报文携带SDP(Session Description Protocol)信息。SDP信息描述了会话的属性和参数,包括媒体类型、传输协议、编解码器、网络地址等。下面是一个示例INVITE报文的SDP内容,并对其中的每一项进行详细解释:
H264的主要目标是实现高的视频压缩比和提供良好的网络亲和性(可适用于各种网络传输),因此在功能层面上划分为视频编码层VCL和网络提取层NAL两层
是的,一般场景是用不到的,我们在开发这块前几年已经开发了非常稳定的RTMP、RTSP直播播放模块,不过也遇到这样的场景,部分设备输出编码后(视频:H.264/H.265,音频:AAC/PCMA/PCMU)的数据,比如无人机或部分智能硬件设备,回调出来的H.264/H.265数据,除了想转推到RTMP、轻量级RTSP服务或GB28181外,还需要本地预览甚至对数据做二次处理(视频分析、实时水印字符叠加等,然后二次编码),基于这样的场景诉求,我们开发了Android平台外部编码数据实时预览播放模块。
不知道大家小时候是否玩过一种动画小人书,连续翻动的时候,小人书的画面就会变成一个动画,类似现在的gif格式图片。
SkeyeVSS视频云支持HEVC/H265编码格式的摄像机直接接入,同时不需要后台转码,直接在WEB网页前端采用H5直接进行无插件播放;
看着精彩的德甲赛事,突然裁判一声口哨,球赛断掉了,屏幕开始自动播放“吃麦趣鸡盒,看德甲比赛”的视频广告
本节重点讲解了 H.264 编码以及 AAC 编码,在对其进行讲解前先介绍了视频编码的实现原理。
Webrtc使用是RTP分装码流,跟视频监控领域,IPTV领域,会议电视一样都是RTP承载媒体流,只不过webrtc信令遵守ICE框架,走自定义信令,IPTV领域走RTSP信令,视频监控走GB28181或者onvif信令,会议电视走h323或SIP协议。但webrtc 不能像传统IPTV和视频监控,会议电视一样可以直接抓包导流播放,因为webrtc的RTP流做了以下工作:
TSINGSEE青犀视频研发团队的成果包含了视频相关的很多内容,有视频流媒体平台EasyNVR、EasyGBS、EasyDSS,有视频智能分析平台EasyCVR,有H265视频播放器EasyWasmPlayer及各种专用直播流播放器,还有视频组件及推流辅助设备等,其中视频流媒体平台内就结合了最新的H265播放器EasyWasmPlayer。
我们在做GB28181设备对接模块和RTMP直播推送模块的时候,遇到这样的技术需求,设备(如执法记录仪)侧除了采集传统的摄像头外,还需要对接比如大疆等第三方数据源,确保按照GB28181规范和RTMP协议规范,接入到国标平台侧和RTMP服务,除了正常的接入需求外,还需要对第三方数据源回调过来的编码后视频、音频数据实时预览和播放。
时至今日,短视频App可谓是如日中天,一片兴兴向荣。随着短视频的兴起,音视频开发也越来越受到重视,但是由于音视频开发涉及知识面比较广,入门门槛相对较高,让许许多多开发者望而生畏。
前言: 大家好,今天给大家推荐一些音视频相关书籍! 一:音视频编解码 《深入理解视频编解码技术:基于H.264标准及参考模型》 《新一代视频压缩编码标准-H.264_AVC(第二版)》 《基于H.264的视频编/解码与控制技术》 《FFmpeg从入门到精通》 《WebRTC权威指南》 《现代电视原理》《数字电视广播原理与应用》 《FFmpeg从入门到精通 FFMPEG视音频编解码基础书籍 》《ffmpeg基础库编程开发》 《音视频开发进阶指南:基于Android与iOS平台的实践》 《视频编解码技术原理
在手机视频播放方面,基于专用芯片的硬解码由于速度快、功耗低,成为了手机视频解码的首选方案。但是,硬解码芯片部署周期长、迭代速度慢,相当程度上制约了手机视频编码技术的更新换代速度。近年来,随着智能手机通用处理能力的不断增强,软件解码由于部署便捷,逐渐开始流行起来。那么,目前硬解码相对于软解码的功耗优势还有多大呢?带着这个问题,我们选择了几款典型手机测试了H.264/AVC硬解、H.264/AVC软解、H.265/HEVC硬解、H.265/HEVC软解和AVS2软解码之间的功耗差异,发现一个重要现象:硬解码相对于软解码的功耗优势正在逐步丧失,近几年生产的智能手机在主流的720P(1280x720)及更小分辨率视频上硬解和软解的功耗差异已经很小。这意味着:手机端视频编码技术的更新迭代速度将会大大加快。下面具体描述测试过程和结果。
【FFmpeg】FFmpeg 相关术语简介 ( 容器 | 媒体流 | 数据帧 | 数据包 | 编解码器 | 复用 | 解复用 ) 【FFmpeg】FFmpeg 相关术语简介 二 【FFmpeg】FFmpeg 帮助文档使用
FFmpeg解码获得的AVPacket只包含视频压缩数据,并没有包含相关的解码信息 (比如:h264的sps pps头信息,AAC的adts头信息),没有这些编码头信息解 码器(MediaCodec)是识别不到不能解码的。在FFmpeg中,这些头信息是保存 在解码器上下文(AVCodecContext)的extradata中的,所以我们需要为每一种 格式的视频添加相应的解码头信息,这样解码器(MediaCodec)才能正确解析 每一个AVPacket里的视频数据。
在FFmpeg的libavcodec模块提供解析数据包和编解码功能。其中,av_parser_parse2()函数用来解析数据包,在使用av_read_frame()读取音视频帧时,会调用到该函数进行数据包解析。关于读取音视频帧的源码分析请查看:av_read_frame()文章。
不久前我们已经在RTMP推送端扩展支持了HEVC(H.265 后文统称H265)编码格式,但是,由于RTMP官方指定的协议格式已经不再更新,官方的播放器的Flash播放器并不支持H265格式的编码数据进行解码播放;现在,我们需要在播放器端解析RTMP流时对H265编码格式进行扩展支持。
常用的文件分辨率有 320*240 640*480 800*600 1280*720 1920x1080
领取专属 10元无门槛券
手把手带您无忧上云