本文为作者原创，转载请注明出处：https://www.cnblogs.com/leisure_chn/p/10584925.html
多媒体技术涵盖的面广，涉及的平台很多，商业化产品也很多。 但是其最核心的技术大致是一样的， 基本框图如下:
前面四次实验，从最简入手，循序渐进，研究播放器的实现过程。第四次实验，虽然音频和视频都能播放出来，但是声音和图像无法同步，而没有音视频同步的播放器只是属于概念性质的播放器，无法实际使用。本次实验将实现音频和视频的同步，这样，一个能够实际使用的简易播放器才算初具雏形，在这个基础上，后续可再进行完善和优化。
Matroska封装格式非常灵活、兼容性好，既适用于本地文件存储又可以进行实时流传输。本篇文章主要探讨Matroska的编解码器映射，如何封装视频流、音频流、字幕流。如果要Matroska的介绍、功能和基本结构，请查看上一篇文章：走进音视频的世界——Matroska封装格式的介绍(一)。
视频传输原理 视频是由一幅幅帧图像和一组音频构成的，视频的播放过程可以简单理解为一帧帧的画面按照时间顺序呈现出来的过程。但是在实际应用中，并不是每一帧都是完整的画面，因为如果每一帧画面都是完整的图片，那么一个视频的体积就会很大。这样对于网络传输或者视频数据存储来说成本太高，所以通常会对视频流中的一部分画面进行压缩（编码）处理。 编码器将多张图像进行编码后生产成一段一段的 GOP ( Group of Pictures ) 如下图， 解码器在播放时则是读取一段一段的 GOP 进行解码后读取画面再渲染显示。GO
音视频同步的目的是为了使播放的声音和显示的画面保持一致。视频按帧播放，图像显示设备每次显示一帧画面，视频播放速度由帧率确定，帧率指示每秒显示多少帧；音频按采样点播放，声音播放设备每次播放一个采样点，声音播放速度由采样率确定，采样率指示每秒播放多少个采样点。如果仅仅是视频按帧率播放，音频按采样率播放，二者没有同步机制，即使最初音视频是基本同步的，随着时间的流逝，音视频会逐渐失去同步，并且不同步的现象会越来越严重。这是因为：一、播放时间难以精确控制，二、异常及误差会随时间累积。所以，必须要采用一定的同步策略，不断对音视频的时间差作校正，使图像显示与声音播放总体保持一致。
音视频领域早期采用模拟化技术，目前已发展为数字化技术。数字化的主要好处有：可靠性高、能够消除传输及存储损耗，便于计算机处理及网络传输等。数字化后，音视频处理就进入了计算机技术领域，音视频处理本质上就是对计算机数据的处理。
在前面一节基于FFmpeg进行RTMP推流(一)我们写了最简单的一版推流代码。但细心调试过的兄弟会发现当我们把文件换成mp4后，发现上面的代码在写入文件头时报错。也就是说上一版的代码是有bug的。
软编（解）的时候CPU负载重，性能比硬编（解）低，但是通用性更好；硬编（解）性能高但是兼容性问题比较突出，特别是在Android平台，碎片化严重，MediaCodec的坑也是不少
保存视频的每一帧，每一个像素没要必要，而且也是不现实的，因为这个数据量太大了，以至于没办法存储和传输，比如说，一个视频大小是 1280×720 像素，一个像素占 12 个比特位，每秒 30 帧，那么一分钟这样的视频就要占 1280×720×12×30×60/8/1024/1024=2.3G 的空间，所以视频数据肯定要进行压缩存储和传输的。 而可以压缩的冗余数据有很多，从空间上来说，一帧图像中的像素之间并不是毫无关系的，相邻像素有很强的相关性，可以利用这些相关性抽象地存储。同样在时间上，相邻的视频帧之间内容相似，也可以压缩。每个像素值出现的概率不同，从编码上也可以压缩。人类视觉系统（HVS）对高频信息不敏感，所以可以丢弃高频信息，只编码低频信息。对高对比度更敏感，可以提高边缘信息的主观质量。对亮度信息比色度信息更敏感，可以降低色度的解析度。对运动的信息更敏感，可以对感兴趣区域（ROI）进行特殊处理。 视频数据压缩和传输的实现与最终将这些数据还原成视频播放出来的实现是紧密相关的，也就是说视频信息的压缩和解压缩需要一个统一标准，即音视频编码标准。
近期在处理视频编码的过程中，我遇到了一个错误：“Application provided invalid, non monotonically increasing dts to muxer in stream 0: -92233720368547”。这个错误消息可能会让人感到困惑，因此我在这篇文章中将解释这个错误的意义以及如何解决它。
注：av_read_frame()获取视频的一帧，不存在半帧说法。但可以获取音频的若干帧。
通常情况下，媒体文件以如MP4，MKV、FLV等等格式存在我们的计算机，手机等设备中，而这些文件格式都属于封装格式，就是把音视频数据按照相应的规范，打包成文件。
前些时间，我在知识星球上创建了一个音视频技术社群：关键帧的音视频开发圈，在这里群友们会一起做一些打卡任务。比如：循序渐进地归纳总结音视频技术知识，绘制一幅音视频知识图谱，你可以看看《音视频知识图谱 2022.03》。再比如：周期性地整理音视频相关的面试题，汇集一份音视频面试题集锦。
大家晚上好，今天给大家分享一些关于音视频里面一些基础的知识点，基础知识点非常重要！
点击上方“LiveVideoStack”关注我们 ▼扫描下图二维码或点击阅读原文▼ 了解音视频技术大会更多信息 翻译：Argus VLC 3.0.17在VLC 3.0.16之后约9个月的时间里，推出了几个新功能，包括支持DTS-HD LBR（低比特率）解码器，支持AV1、E-AC3和GeoVision解码器的新FOURCC，支持DAV视频文件，WebP图像映射，以及支持MP4文件的未压缩音频（ISO/IEC 23003-5）。 这个版本还带来了许多改进，如对一些AMD的GPU驱动程序进行了更好的硬件解
AVFormatContext 是一个贯穿始终的数据结构，很多函数都用到它作为参数，是输入输出相关信息的一个容器，本文讲解 AVFormatContext 的编解码层，主要包括三大数据结构：AVStream，AVCodecContex，AVCodec。
PotPlayer，免费全能影音播放器，堪称Windows平台最强本地视频播放器。PotPlayer播放器，拥有强劲播放引擎加速，支持DXVA, CUDA, QuickSync，多媒体播放器支持蓝光3D，内置强大的解码器及滤镜/分离器，支持自定义添加解码器，对字幕的支持非常优秀，能够兼容特效字幕及在线搜索字幕实时翻译。
大流程可以划分为输入、输出、转码、播放四大块。其中转码涉及比较多的处理环节，从图中可以看出，转码功能在整个功能图中占比很大。转码的核心功能在解码和编码两个部分，但在一个可用的示例程序中，编码解码与输入输出是难以分割的。解复用为解码器提供输入，解码器输出原始帧，可进行各种复杂的滤镜处理，滤镜处理后的帧经编码器生成编码帧，多路流的编码帧经复用器输出到输出文件。
我记得之前在多媒体文件格式剖析：M3U8篇中讲解了什么是流式视频，什么不是流式视频？其实有一个更简单更明确的解释，能够用于直播的格式是流式视频格式，反之则不是。
工欲善其事，必先利其器，断点调试，对我们梳理流程排查问题十分重要，可以ffmpeg的调试可以在XCode、VS code以及QT等ide上进行方便的调试分析。本篇我们以XCode为例来先介绍下ffplay的断点调试，以ffmpeg4.4版本来进行分析。
FFMpeg 作为音视频领域的开源工具，它几乎可以实现所有针对音视频的处理，本文主要利用 FFMpeg 官方提供的 SDK 实现音视频最简单的几个实例：编码、解码、封装、解封装、转码、缩放以及添加水印。
目前显示多基于横屏的情况设计布局, UI, 图片, 视频等显示. 而常用到的MIPI屏大多都是竖屏, 为避免重新调整布局, 显示提供了竖屏旋转成横屏的显示方式, 节省客户开发时间.
目前TSINGSEE青犀视频的视频上云服务平台EasyCVR已经可集成海康EHome私有协议，并且在前文中我也跟大家讲过EHome协议的配置和调用流程，有兴趣的可以阅读一下：配置及协议介绍、Ehome协议调用流程介绍。
关于Linux下X264和FFMPEG库的编译安装方法参考这里：https://blog.csdn.net/xiaolong1126626497/article/details/104919095
GOM player 是一款本身装有视频播放所需的解码，及占用系统资源少，并且能以最优秀的画质来观看多种格式影片的播放程序。
将封装格式解压后可以得到压缩过的音视频等. 将压缩过的视频解压后可以得到 视频像素数据(RGB,YUV等).常见的视频压缩格式有H.264, MPEG4等…
FFmpeg既是一款音视频编解码工具，同时也是一组音视频编解码开发套件，作为编解码开发套件，它为开发者提供了丰富的音视频处理的调用接口。 FFmpeg提供了多种媒体格式的封装和解封装，包括多种音视频编码、多种协议的流媒体、多种色彩格式转换、多种采样率转换、多种码率转换等；FFmpeg框架提供了多种丰富的插件模块，包含封装与解封装的插件、编码与解码的插件等。
视频流媒体中程中视频数据的传输占据了绝大部分的带宽，如何提升编码效率，使用更少的带宽，提供更优质的画面质量，是音视频开发人员一直努力的重点。HEVC(High Efficiency Video Coding，也叫H.265)编码格式的推出，给这一方向带来了突破点，但由于其算法复杂度较高，前期未曾得到普遍应用，而随着移动设备计算能力的提高和越来越多的设备开始支持HEVC的硬件编/解码，直播平台也开始逐渐引入HEVC视频格式。
出品 | OSC开源社区（ID：oschina2013 在 FFmpeg 5.1 发布约 6 个月后，FFmpeg 6.0 "Von Neumann" 现已正式发布。该版本包含了许多新的编码器和解码器、过滤器以及 FFmpeg CLI 工具方面的改进。同时改变了发行方式，所有主要版本现在都会增加 ABI 版本；官方计划每年推出一个主要版本更新。 另一个特定的更改是，废弃的 API 将在 3 个版本后，在下一个主要版本中被删除；一个主要版本的最后一个次要版本将是 LTS 版本。这意味着 FFmpeg 此后的发
ffmpeg命令- 用于转码的应用程序, 也可以从url/现场音频/视频源抓取输入源
（本文基本逻辑：TS 封装格式概览 → TS 层解析 → PES 层解析 → ES 层解析）
教科书般的教程、课程中对视频文件结构的描述非常详细，此处不赘述，简单地说，视频文件也是一种文件，是文件，就是一堆二进制数的集合，而且是一个一维的二进制数的集合。因此，视频文件中的视频流、音频流，甚至可能包含的字幕流是如何存放的呢？
在直播拉流的时候，经常会遇到这样的情况，画面会比声音延迟个几秒，往往会先听到声音后才看到画面，或者是声音和画质明显对不上，这样就造成了我们常说的音视频画面不同步的情况。那问题原因是什么呢？我们应该如何避免？接下来我们以腾讯云直播为例来分析下这个问题。
MPEG2-TS（Transport Stream“传输流”；又称TS、TP、MPEG-TS或M2T）是用于音效、图像与数据的通信协定，最早应用于DVD的实时传送节目。 区别： DVD节目中的MPEG2格式，确切地说是MPEG2-PS，全称是Program Stream（程序流），而TS的全称则是Transport Stream（传输流）。MPEG2-PS主要应用于存储的具有固定时长的节目，如DVD电影，可添加字幕等一些程序操作。而MPEG-TS则主要应用于实时传送的节目，比如实时广播的电视节目。 简单地说，将DVD上的VOB文件的前面一截cut掉（或者是数据损坏数据）就会导致整个文件无法解码，而电视节目是任何时候打开电视机都能解码（收看）的。所以MPEG2-TS格式的特点就是从视频流的任一片段开始都是可以独立解码。
大家好，从本文开始我们将从 Android 音视频专题开始探索，并按照 iOS/Android 音视频开发专题介绍 依次开始。iOS 音视频专题将在 Android 音视频专题结束后进行。 在进入实战之前，我们有必要了解下音视频相关术语。
AVFormatContext 是一个贯穿始终的数据结构，很多函数都用到它作为参数，是输入输出相关信息的一个容器，本文讲解 AVFormatContext 的封装层，主要包括两大数据结构：AVInputFormat，AVOutputFormat。
大家好，我是小涂，今天继续给大家分享ffplay源码解析，今天也是最后一篇关于read_thread线程的解析，分享完这个之后，会接着分享视频和音频解码线程以及音频输出、视频输出模块，大概率每个礼拜一篇，很快就会进入到实战篇写一个播放器，前期解析ffplay源码，主要是要先了解这个优秀的播放器框架，后期我们就可以在这个基础上借鉴前人的优秀思想，来做一个自己的播放器。
前面分析了TS封装格式的码流，从实际应用上讲，TS这种封装格式文件应用的场合比较多，机顶盒，苹果家族产品，游戏直播等领域现在都用。最新的HLS低延迟规范也进行优化了协议，降低了HLS延时，所以还有比较好的前景和生命周期。
I帧：I帧(Intra-coded picture, 帧内编码帧，常称为关键帧)包含一幅完整的图像信息，属于帧内编码图像，不含运动矢量，在解码时不需要参考其他帧图像。因此在I帧图像处可以切换频道，而不会导致图像丢失或无法解码。I帧图像用于阻止误差的累积和扩散。在闭合式GOP中，每个GOP的第一个帧一定是I帧，且当前GOP的数据不会参考前后GOP的数据。
前文中，我们基于 FFmpeg 利用 OpenGL ES 和 OpenSL ES 分别实现了对解码后视频和音频的渲染，本文将实现播放器的最后一个重要功能：音视频同步。
① FFMPEG 初始化 : 参考博客 【Android FFMPEG 开发】FFMPEG 初始化 ( 网络初始化 | 打开音视频 | 查找音视频流 )
注：参考自bilibili系列视频，从0开始做播放器-第6章-图像编码的基础概念（理论课）https://www.bilibili.com/video/BV1PK41157jz
Hi3798MV310是用于IPTV/OTT机顶盒市场的支持4KP60 解码的超高清高性能SOC芯片。集成4核64位高性能Cortex A53处理器和多核高性能 2D/3D加速引擎；支持H.265/AVS2 4Kx2K@P60 10bit 超高清视频解码，高性能的 H.265 高清视频编码，HDR视频解码及显示，HDR转SDR，BT.2020，Dolby 和 DTS 音频处理；内置 USB2.0 等丰富外设接口。可支持客户实现超高清业务部署，在图像质量、码流兼容性、视频播放的流畅性以及整机性能方面保持业界最好的用户体验，同时满足不断增长的视频通信、卡拉 OK、云游戏、多屏互动等增值业务需求。
在编辑场景用 AVPlayer 来实现预览播放器时，对视频中某一段内容进行加速播放的实现代码如下：
大家好，我是小涂，今天继续给大家分享播放器里面的相关知识，本篇文章主要是分享ffplay里面的视频解码线程相关源码，废话就不多说，开始开肝！
（本文基本逻辑：视频编码的理论基础是什么 → H.264 视频编码的基本概念、编码工具、编码流程及码流结构 → H.265 的编码工具及改进 → H.266 的编码工具及改进）
音频帧的概念没有视频帧那么清晰，几乎所有视频编码格式都可以简单的认为一帧就是编码后的一副图像，而音频帧会因编码格式的不同而不同，如 PCM 音频流可以直接进行播放，下面以 MPEG 音频帧格式为例介绍音频帧。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
云直播
