视频编解码硬件方案最早是在嵌入式领域中广泛存在，如采用DSP,FPGA，ASIC等，用来弥补嵌入式系统CPU等资源能力不足问题，但随着视频分辨率越来越高（从CIF经历720P，1080P发展到4K，8K），编码算法越来越复杂（从mpeg2经历h264,发展到h265）,PC的软件规模也越来越庞大，视频应用也越来也丰富，单独靠CPU来编解码已经显得勉为其难，一种集成在显卡中gpu用来参与编解码工作已经成为主流。
ffmpeg主要用于音视频转码，以及增删水印等处理，是一款简单实用且强大的音视频处理工具。
在使用视频处理工具或者播放器时，有时我们可能会遇到错误信息 "Could not find codec parameters for stream 0 (Video: h264, none)"。这个错误提示说明在当前的环境中找不到视频流的编解码器参数，导致无法正确解码视频数据。本文将详细介绍该错误产生的原因以及解决方法。
AVCodecContext 结构表示程序运行的当前 Codec 使用的上下文，着重于所有 Codec 共有的属性(并且是在程序运行时才能确定其值)和关联其他结构的字段。
FuboTV 是一家美国流媒体电视服务公司，为美国、加拿大和西班牙的客户提供服务，主要专注于分发体育直播的频道。根据国家/地区的不同，Fubo 提供的频道可能包括访问 NFL、MLB、NBA、NHL、MLS、CPL 和国际足球，以及新闻、网络电视连续剧和电影。
因为工作原因，接触编解码也有一段时间了。AVC，HEVC，大大小小的功能都也接触了一些，关于编解码的原理的书和文章自己一直在看。从入门到略懂，感觉有些零零碎碎，或不完整，似乎串不成体系。有些小功能，知道是知道，并不知道它的意义和作用，时间一长也会慢慢忘记。 反思了一下，或许很多东西，还是需要自己动手做一遍，会理解的更深更透彻一些，就像费曼学习法，你能讲出来，才说明懂了，这个也一样，你能把功能实现出来，才说明你真的明白了里面的流程和逻辑。于是乎，在今年过年期间，突然萌生出了写一个解码器的想法，而且一萌生就一直压不住了，一直想赶快动键盘写起来。 其实目前市面上开源好用的解码器有不少，像ffmpeg，x264等等。自己这个工程，应该就是单纯的一个学习工程吧，估计最后再怎么优化也达不到这些大名鼎鼎的工程的效果和功能，但是那又怎么样呢，过程和经历也很棒，不是吗？ 刚开始的时候是想写过一个编码器的，思考了一下之后很快就放弃了，我目前的想法只是想熟悉协议，并不是侧重于编码算法，相比之下，编写一个解码器所需要的的知识正是我所需要的。 这就成了这一系列文章的的起因了，算是自己一边写代码，一边写总结吧。 虽说是从“零”开始，但是编解码的基础知识还是要有一些储备的，我会在每一章里对解码所涉及到的知识点做一个介绍和讲解，但是太零碎的，就不会一一说明了。如果知识点太大，可能会单独写一篇来总结。
相信很多人和我一样，刚开始的时候都会很好奇，为什么h264可以实现这么强大的压缩比，要知道，1张1080p的YUV420就是3MB，想实现1秒钟30帧，千兆网就基本跑满了，这也太可怕了，基本上只有条件很好的局域网才能达到这个水平。但是h264的出现把这个数据量降到了百分之一，2个数量级，这实在太可怕了，技术的发展真的是强大。
在gstreamer开发中，关键是要知道命令行实现，如果命令验证没有问题，再将命令集成代码工程化，或者找找对应的API来实现。本文总结工作常用命令行实现(测试环境windows)。
现在来写下s5pv210的h264解码，这一章有些部分我理解的不是很透彻，只能写个大概了。希望看到的人能给出些意见，有些地方写错的还望指正出来！
dll自己百度下载 hi_h264dec.dll hi_h264dec_w.dll
通过上一篇文章，我们用ffmpeg分离出一个多媒体容器中的音视频数据，但是很可能这些数据是不能被正确解码的。为什么呢？因为在解码这些数据之前，需要对解码器做一些配置，典型的就是目前流行的高清编码“黄金搭档”组合H264 + AAC的搭配。本文将讲述H264和AAC的关键解码配置参数的解析，如果没有这些配置信息，数据帧往往不完整，导致了解码器不能解码。 H264的配置信息解析 前面我们知道，ffmpeg的avformat_find_stream_info函数可以取得音视频媒体多种，比如播放持续时间、音视频压缩
ffplay 命令的 -autoexit 参数 用于 设置 视频播放完毕后 自动退出播放器 ; 默认情况下 , ffplay 播放完视频后 保持开启状态 , 需要等待用户按下 esc 键手动退出 ;
默认的编译会生成4个可执行文件和8个静态库。可执行文件包括用于转码、推流、Dump媒体文件的ffmpeg、用于播放媒体文件的ffplay、
在视频编码中，延迟是一个常见的问题。对于实时性要求较高的应用（如视频直播、视频会议等），延迟问题尤为重要。本文将重点讲解FFmpeg中H264和H265编码器的延迟问题，以及如何优化和降低编码延迟。
EasyRTC是TSINGSEE青犀团队去年研发的企业远程视频通话会议系统，适合召开各种现场会议，实现多个会议现场之间的视频多画面轮换，支持即时会议、理会、多组会议等会议形式。并将视频会议以图文+视频+现场声音实时广播的形式通过互联网对外直播。
本文基于之前的Demo添加了FFmpeg使用MediaCodec来硬解码的方式，包括解码出buffer再利用OpenGL进行渲染上屏和直接解码到Surface然后上屏两种方式
原文:http://www.mworkbox.com/wp/work/314.html MP4的视频H264封装有2种格式：h264和avc1，对于这个细节，很容易被忽略。笔者也是在改编LIVE555流媒体时，增加mp4文件类型支持时遇到了该问题。 (一)首先，从原理上了解一下这2种格式的区别： AVC1 描述:H.264 bitstream without start codes.一般通过ffmpeg转码生成的视频，是不带起始码0×00000001的。 H264 描述:H.264 bitstream with start codes.一般对于一下HDVD等电影的压制格式，是带有起始码0×00000001的。 (二)其次，通过VLC播放器，可以查看到具体的格式。打开视频后，通过菜单【工具】/【编解码信息】可以查看到【编解码器】具体格式，举例如下，编解码器信息： 编码: H264 – MPEG-4 AVC (part 10) (avc1) 编码: H264 – MPEG-4 AVC (part 10) (h264) (三)最后，分享一下ffmpeg demux MP4文件后，转换视频流为live555可直接使用的h264 ES流的经验和方法： 针对（avc1），av_read_frame后，取前四个字节为长度，把前四字节直接替换为0×00,0×00,0×00,0×01即可，但注意每个frame可以有多个NAUL：
FFmpeg是音视频领域很有名的一个库, 这里从两方面介绍, 一方面根据FFMPEG的命令行工具介绍, 介绍这些命令行工具的使用方法, 满足一般用户要求. 还有一方面从组件/库的划分来介绍, 介绍FFMPEG是有哪些组件和库组成, 每一个库的作用, 便于后续的自定义开发.
ffmpeg包含了很多的音视频解码器，本文试图通过对ffmpeg的简单分析提取h264解码器.
网络视频一直都很火。虽然在页面上嵌入 Instagram 和 Youtube 视频非常简单，但是有越来越多的需求 —— 比如许多电子商务的场景 —— 要求定制的视频传输方法。
H.264，同时也是MPEG-4第十部分，是由ITU-T视频编码专家组（VCEG）和ISO/IEC动态图像专家组（MPEG）联合组成的联合视频组（JVT，Joint Video Team）提出的高度压缩数字视频编解码器标准。这个标准通常被称之为H.264/AVC（或者AVC/H.264或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC）而明确的说明它两方面的开发者。
视频会议在人们的日常生活中使用愈发频繁，尤其是在新冠肺炎疫情的影响下视频会议市场急剧增长，由此引发了思科网讯视频技术的不断更新。本次分享，我们邀请到了思科协作技术事业部的首席工程师Thomas Davies先生，他向我们分享了AV1的发展历程，开发AV1时所受到的挑战，以及AV2的发展前景及其在实时通信中的作用。
FFmpeg解码获得的AVPacket只包含视频压缩数据，并没有包含相关的解码信息 （比如：h264的sps pps头信息，AAC的adts头信息），没有这些编码头信息解 码器（MediaCodec）是识别不到不能解码的。在FFmpeg中，这些头信息是保存 在解码器上下文（AVCodecContext）的extradata中的，所以我们需要为每一种 格式的视频添加相应的解码头信息，这样解码器（MediaCodec）才能正确解析 每一个AVPacket里的视频数据。
3.1 FFmpeg本身支持一些编码、封装与协议，但是支持的依然有限，有些是因为licence，有些是因为相对来说比较大，FFmpeg所做的是提供一套基础的框架，而这些编码、封装与协议可以作为一个FFmpeg的模块挂在FFmpeg中，这些模块以第三方的外部库的方式提供支持，可以通过FFmpeg的源码的configure进行查看FFmpeg默认支持的编码、封装与协议的支持，不支持的可以再configure –help的时候查看所支持的第三方外部库，可以通过对应的参数选项进行支持：
原作者：Taein Kim, Ploy Temiyasathit, Haixiong Wang
最开始做的ffmpeg保存视频文件，就是直接保存的裸流数据，裸流数据一般是H264格式的数据，这种数据文件可以用部分播放器播放，由于不是标准的格式，很多播放器其实不支持的，需要安装对应的解码器才行。后面发现安装好K-Lite解码器后，连系统自带的播放器都可以正常播放H264视频流文件，而且如果同步保存了同名文件的aac音频文件放在同目录下的话，声音都能正常同步播放，可能这是播放器做的处理吧。
在前文《视频编解码硬件方案漫谈》中我们介绍硬件视频编解码的一般方案，本文我们进一步介绍音视频编解码如何在ffmpeg使用显卡硬件进行加速。
本文来自The broadcast knowledge的演讲，演讲者是FuboTV公司的工程负责人Nick Krzemienski，演讲内容为HLS和DASH多编解码器的编码和打包。
本节重点讲解了 H.264 编码以及 AAC 编码，在对其进行讲解前先介绍了视频编码的实现原理。
在H264的帧内预测选择了最佳预测模式后，需要对选择的每个4x4帧内预测模式进行编码成信号，以便后面传输给解码器。但是一个图像帧的4x4块很多，这样会需要大量比特来表示。考虑到相邻的4x4块本身是强相关的，因此它们的帧内预测模式也是强相关的。利用这个特性，我们可以对图像帧的预测模式进行压缩编码输出，从而在保证相同质量的情况下，达到降低视频码率的目的。
上一篇文章中我介绍了如何使用MediaCodec编码，今天我们再来分析一下如何通过 MediaCodec 进行解码。
H.264从1999年开始，到2003年形成草案，最后在2007年定稿有待核实。在ITU的标准⾥称为H.264，在MPEG的标准⾥是MPEG-4的⼀个组成部分–MPEG-4 Part 10，⼜叫Advanced Video Codec，因此常常称为MPEG-4 AVC或直接叫AVC。
在 ffmpeg 命令中 , -vframes 参数 的 作用是 指定要输出的视频帧数 , 通过该参数 可以 控制 视频处理的长度 , 即 : 在输出多少帧后 停止处理 视频流 ;
都0202年了，本文基于FFmpeg4.2.1,将使用最新版的api。让av_register_all()见鬼去吧! FFmpeg的文章绝大多数都是3.X的，很多方法都过时了。对于喜新厌旧的洁癖君而言，满屏飘黄的警告、运行一下全是过时的警告是多么糟心。本文根据源码中的exsample进行改编，删繁就简,对于判空，校验返回值，打印错误什么的，自己在使用时注意一下，自行处理。 ---- 1. 讲个小故事 为了让你明白这篇文章是在干嘛，讲个小故事先: 捷特有两个护体神兽：白皇和黑皇 白皇善鸣，声震天地
FFmpeg是一个完整的跨平台音视频解决方案，它可以用于处理音频和视频的转码、录制、流化处理等应用场景。官网：http://ffmpeg.org/。FFmpeg有三大利器，分别是ffmpeg、ffprobe、ffplay。今天主要介绍ffmpeg，它是FFmpeg用于音视频转码，转封装、转推流的基础工具。
如果大家有不懂的可以看我之前的文章：Android音视频开发——MedCodec实现屏幕录制编码成H264
本篇介绍下H264和H264的编码格式，包括avcc，annexb，以及转换方法。annexb 用于实时流的场景，avcc用于多媒体文件，如mp4,mkv等场景。
遇到的问题：使用ffmpeg直接读取avc1编码的mp4视频，将读取到的帧写下来（H264码流），播放失败。 原因： ffmpeg解码获取的AVPacket只包含视频压缩数据，并没有包含相关的解码信息（比如：h264的sps,pps头信息），这些解码信息包括编码的profile，level，图像的宽和高，deblock滤波器等。没有这些编码头信息解码器就不能进行解码。
转自：http://www.mworkbox.com/wp/work/314.html
注：参考自bilibili系列视频，从0开始做播放器-第6章-图像编码的基础概念（理论课）https://www.bilibili.com/video/BV1PK41157jz
无论是解析视频文件或这通过网络传输, 其实都是一串字节序列. H264码流就是按照一定的规则组织排列的字节串.
H.264编码将一帧数据分成多个块，其中每个块可以单独进行编码。编码的过程包括预测、变换和量化等步骤。
在偶遇FFmpeg（三）——Android集成这边文章中曾经介绍过FFmpeg和Android的交叉编译。文章中也提到过如何裁剪SO文件大小的方式。 这边文章就这个问题。进行实战。
在直播系统中，除了直播音视频之外，有时候还想从主播端发布文本信息等，这些信息可以不通过视频传输通道发送给用户播放端，但如果传输的数据想和视频保持精准同步，那最好的办法就是这些信息和视频数据打包在一起传输, 通过h264 sei方式就可以把数据放入h264 Access Unit中传输。
最近TSINGSEE青犀视频开发人员在开发WebRTC的ffmpeg编译，在目前阶段已经开始着手对视频流的浏览器播放做开发。对于WebRTC中H264编码而言，WebRTC主要是针对VP8和VP9编码协议进行传播。
点击上方“LiveVideoStack”关注我们 ▲扫描图中二维码或点击阅读原文▲ 了解音视频技术大会更多信息 // 编者按：Gstreamer作为一个比较流行的开源多媒体框架，其优秀的架构使其具有高度的模块化和良好的扩展性，并具有广泛的应用前景。LiveVideoStackCon2022上海站大会我们邀请到了英特尔 加速计算系统与图形部工程师 何俊彦老师，为我们详细介绍了Gstreamer的框架和特点，视频的模块化处理，以及其硬件加速的实现与应用案例，并总结和展望Gstreamer的发展与趋势
H.264，同时也是MPEG-4第十部分，是由ITU-T视频编码专家组（VCEG）和ISO/IEC动态图像专家组（MPEG）联合组成的联合视频组（JVT，Joint Video Team）提出的高度压缩数字视频编解码器标准。
RTMP（Real Time Messaging Protocol）是专门用来传输音视频数据的流媒体协议，最初由Macromedia 公司创建，后来归Adobe公司所有，是一种私有协议，主要用来联系Flash Player和RtmpServer，如FMS, Red5, crtmpserver等。RTMP协议可用于实现直播、点播应用，通过FMLE（Flash Media Live Encoder）推送音视频数据至RtmpServer，可实现摄像头实时直播。不过，毕竟FMLE应用范围有限，想要把它嵌入到自己的程序中，还是要自己来实现RTMP协议的推送。本人实现了一个RTMPLiveEncoder，通过采集摄像头视频和麦克风音频，并进行H.264和AAC编码，然后发送到FMS和crtmpserver上，实现实时直播，可以通过flash player正常观看，目前效果良好，延迟时间在2秒左右。本文就介绍一下RTMPLiveEncoder的主要思路和关键点，以期对需要这方面技术的朋友有所帮助。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
