我们在做Windows平台Unity播放RTMP或RTSP的时候，遇到这样的问题，比如展会、安防监控等场景下，需要同时播放多路RTMP或RTSP流，这样对设备性能，提出来更高的要求。
在刚提出4K视频的时候，大多数人都觉得没有必要，4K的出现，意味着更高的硬件规格和传输要求，1080P看的很爽、很清晰，完全满足了日常的需求。随着电视的尺寸越来越大，原本1080P成像已经无法满足人们对于细节的极致追求，4K视频不仅成像更细腻，在细节处理上优势也非常明显，颜色也更亮丽、饱满，逼真，给人身临其境的感觉。4K视频具有高分辨率、宽色域、高动态范围等优势，随着5G技术和H.265(HEVC)编码标准的出炉，4K视频直播迎来了曙光。
EasyRTC是TSINGSEE青犀团队去年研发的企业远程视频通话会议系统，适合召开各种现场会议，实现多个会议现场之间的视频多画面轮换，支持即时会议、理会、多组会议等会议形式。并将视频会议以图文+视频+现场声音实时广播的形式通过互联网对外直播。
本文基于之前的Demo添加了FFmpeg使用MediaCodec来硬解码的方式，包括解码出buffer再利用OpenGL进行渲染上屏和直接解码到Surface然后上屏两种方式
时至今日，短视频App可谓是如日中天，一片兴兴向荣。随着短视频的兴起，音视频开发也越来越受到重视，但是由于音视频开发涉及知识面比较广，入门门槛相对较高，让许许多多开发者望而生畏。
不知道大家小时候是否玩过一种动画小人书，连续翻动的时候，小人书的画面就会变成一个动画，类似现在的gif格式图片。
看着精彩的德甲赛事，突然裁判一声口哨，球赛断掉了，屏幕开始自动播放“吃麦趣鸡盒，看德甲比赛”的视频广告
在手机视频播放方面，基于专用芯片的硬解码由于速度快、功耗低，成为了手机视频解码的首选方案。但是，硬解码芯片部署周期长、迭代速度慢，相当程度上制约了手机视频编码技术的更新换代速度。近年来，随着智能手机通用处理能力的不断增强，软件解码由于部署便捷，逐渐开始流行起来。那么，目前硬解码相对于软解码的功耗优势还有多大呢？带着这个问题，我们选择了几款典型手机测试了H.264/AVC硬解、H.264/AVC软解、H.265/HEVC硬解、H.265/HEVC软解和AVS2软解码之间的功耗差异，发现一个重要现象：硬解码相对于软解码的功耗优势正在逐步丧失，近几年生产的智能手机在主流的720P（1280x720）及更小分辨率视频上硬解和软解的功耗差异已经很小。这意味着：手机端视频编码技术的更新迭代速度将会大大加快。下面具体描述测试过程和结果。
随着互联网的发展，传统安防行业已不再满足于仅仅通过一台PC机器，或者一台NVR接入摄像机源进行录像和监控的基本要求，人们迫切的需要利用目前相当便利的网络环境，以便能实现随时随地的观看到适应各种网络环境和各种终端设备的低延时的音视频视频监控，录像取证和应急处理，而不再受到时间和地域的限制。同样，对于互联网服务，PC电脑也不再是唯一选择，智能手机、平板电脑、特定的移动终端等都是可选择的用户终端硬件方式；因此，我们需要一款能将安防协议，电视广播协议以及其他各种格式的流媒体协议接入到互联网上来，通过一种统一格式的协议进行多平台多终端直播。
我们在对接开发者的时候，遇到这样的诉求：除了正常的RTMP、RTSP直播播放外，有些硬件设备输出编码后（H.264/H.265）的数据，比如无人机或类似硬件产品，回调出来的H.264/H.265数据，除了正常转推到RTMP、轻量级RTSP服务或GB28181外，还需要本地预览甚至重新对数据做二次处理，基于这样的场景诉求，我们开发了外部编码后数据实时预览播放模块。
Android 从 API 16 开始提供java层的 MediaCodec 视频硬解码接口；从 API 21，也就是Android 5.0 开始提供 native 层的 MediaCodec的接口。
前言 H.264是目前很流行的编码层视频压缩格式，目前项目中的协议层有rtmp与http，但是视频的编码层都是使用的H.264。 在熟悉H.264的过程中，为更好的了解H.264，尝试用VideoToolbox硬编码与硬解码H.264的原始码流。 介绍 1、H.264 H.264由视讯编码层(Video Coding Layer，VCL)与网络提取层(Network Abstraction Layer，NAL)组成。 H.264包含一个内建的NAL网络协议适应层，藉由NAL来提供网络的状态，让VCL有更
最开始做的ffmpeg保存视频文件，就是直接保存的裸流数据，裸流数据一般是H264格式的数据，这种数据文件可以用部分播放器播放，由于不是标准的格式，很多播放器其实不支持的，需要安装对应的解码器才行。后面发现安装好K-Lite解码器后，连系统自带的播放器都可以正常播放H264视频流文件，而且如果同步保存了同名文件的aac音频文件放在同目录下的话，声音都能正常同步播放，可能这是播放器做的处理吧。
H264的主要目标是实现高的视频压缩比和提供良好的网络亲和性（可适用于各种网络传输），因此在功能层面上划分为视频编码层VCL和网络提取层NAL两层
MPEG-4 Part 14定义了MPEG-4文件格式，即mp4后缀文件。mp4文件格式只是MPEG-4标准中的一小部分
默认，chrome只会打开错误级别，很多调试日志都不输出。在启动时，通过命令行打开日志级别即可。
是的，一般场景是用不到的，我们在开发这块前几年已经开发了非常稳定的RTMP、RTSP直播播放模块，不过也遇到这样的场景，部分设备输出编码后（视频：H.264/H.265，音频：AAC/PCMA/PCMU）的数据，比如无人机或部分智能硬件设备，回调出来的H.264/H.265数据，除了想转推到RTMP、轻量级RTSP服务或GB28181外，还需要本地预览甚至对数据做二次处理（视频分析、实时水印字符叠加等，然后二次编码），基于这样的场景诉求，我们开发了Android平台外部编码数据实时预览播放模块。
大部分的格式转换工具比如格式化工厂等，都用到了ffmpeg来处理，ffmpeg编译后生成的ffmpeg.exe、ffplay.exe、ffprobe.exe等可执行文件，其实就封装了众多牛逼的功能，ffprobe查看媒体文件头信息的工具，ffplay用于播放媒体文件的工具，尤其是ffmpeg.exe，强大的媒体文件转换工具，可以转换任何媒体文件，还可以用自己的 AudioFilter 以及 VideoFliter 进行处理和编辑，比如下面的一些功能。
我们在做GB28181设备对接模块和RTMP直播推送模块的时候，遇到这样的技术需求，设备（如执法记录仪）侧除了采集传统的摄像头外，还需要对接比如大疆等第三方数据源，确保按照GB28181规范和RTMP协议规范，接入到国标平台侧和RTMP服务，除了正常的接入需求外，还需要对第三方数据源回调过来的编码后视频、音频数据实时预览和播放。
16年壮观的直播百团大战相信大家历历在目，至19年初所剩无几的直播寡头，来去如风的直播战场，离不开背后强大的直播技术支撑，本文通过直播基础技术介绍、剖析企鹅电竞直播构架、关键技术、常见问题排查、带领大家了解直播技术细节。 直播基础技术扫盲 分辨率 分辨率是度量位图图像内数据量多少的一个参数。通常表示成每英寸像素（Pixel per inch, ppi）和每英寸点（Dot per inch, dpi），包含的数据越多，图形文件的长度就越大，也能表现更丰富的细节。但更大的文件需要耗用更多的计算机资源，更多的内
随着通信技术的不断发展，互联网信息的传播与娱乐方式经历了从文字到图片再到音视频的转变，音视频通信，直播互动，短视频等应用百花齐放，特别是5G时代的到来，互联网对音视频开发者的需求会越来也大，有兴趣的同学可以把握机遇，提升自己，加入到这个行业当中。
视频（Video） 泛指将一系列静态影像以电信号的方式加以捕捉、 纪录、 处理、 储存、 传送与重现的各种技术。
用ffmpeg来做音视频同步，个人认为这个是ffmpeg基础处理中最难的一个，无数人就卡在这里，怎么也不准，本人也是尝试过网上各种demo，基本上都是渣渣，要么仅仅支持极其少量的视频文件比如收到的数据包是一帧视频一帧音频的，要么根本没法同步歪七八糟的，要么进度跳过去直接蹦蹦蹦崩溃的，其实最完美的音视频同步处理demo就是ffplay，我亲测过几十种各种各样的音视频本地文件，数十种视频流文件，都是非常完美，当然啦这是亲生的啦，不完美还玩个屁。
随着移动网络速度越来越快、质量越来越来，实时音视频技术已经在各种应用场景下全面开花，语音通话、视频通话、视频会议、远程白板、远程监控等等。
ffmpeg主要用于音视频转码，以及增删水印等处理，是一款简单实用且强大的音视频处理工具。
我们在做Windows平台RTMP和RTSP播放模块对接的时候，有开发者需要在wpf下调用，如果要在wpf下使用，只需要参考C#的对接demo即可，唯一不同的是，视频流数据显示的话，要么通过控件模式，要么可以让RTMP、RTSP播放模块回调rgb数据上来，在wpf直接绘制即可。
前言 之前偶然看到一个PPT，是一些视频特效的讲解。首页如下： PPT解析了模糊镜像、电击效果、灵魂出窍、动态晕影等视频处理效果，最后推荐作者自己写的书： 在“音视频进阶”、“唱吧核心架构开发”
在视频编码中，延迟是一个常见的问题。对于实时性要求较高的应用（如视频直播、视频会议等），延迟问题尤为重要。本文将重点讲解FFmpeg中H264和H265编码器的延迟问题，以及如何优化和降低编码延迟。
2015年，我们在做移动单兵应急指挥项目的时候，推送端采用了RTMP方案，这在当时算是介入RTMP比较早的了，RTMP推送模块做好以后，我们找了市面上VLC还有Vitamio，来测试整体延迟，实际效果真的不尽人意，大家知道，应急指挥系统，除了稳定性外，对延迟有很高的要求，几秒钟（>3-5秒）的延迟，是我们接受不了的，VLC之类播放器，虽然功能庞大，点播体验可满足大多场景诉求，直播场景确实不尽人意。
视频编解码硬件方案最早是在嵌入式领域中广泛存在，如采用DSP,FPGA，ASIC等，用来弥补嵌入式系统CPU等资源能力不足问题，但随着视频分辨率越来越高（从CIF经历720P，1080P发展到4K，8K），编码算法越来越复杂（从mpeg2经历h264,发展到h265）,PC的软件规模也越来越庞大，视频应用也越来也丰富，单独靠CPU来编解码已经显得勉为其难，一种集成在显卡中gpu用来参与编解码工作已经成为主流。
用ffmpeg来处理USB摄像头，是前段时间研究视频监控ffmpeg内核的时候搞定的，既然ffmpeg这么牛逼的库可以解析各种音视频，我想处理个本地USB摄像头应该也不是什么难事，果真搜索也是一大堆，当然主要也是因为有个项目的应用需要用到ffmpeg来处理本地USB摄像头，需要拿到每张图片做智能分析，用Qt自带的camera类不大好处理，刚好将ffmpeg的处理流程都搞清楚了，索性直接用ffmpeg来直接处理好了，用上这么强大的解码库，理论上支持各种USB摄像头。本地USB摄像机不需要硬解码，视频流编码类型为 AV_CODEC_ID_RAWVIDEO 像素格式为 AV_PIX_FMT_YUYV422 不经过解码操作直接就可显示。
在gstreamer开发中，关键是要知道命令行实现，如果命令验证没有问题，再将命令集成代码工程化，或者找找对应的API来实现。本文总结工作常用命令行实现(测试环境windows)。
目前 H.264 流行的包装方式有两种，一种叫做 AnnexB，一种叫做 avcC。对于这两种格式，各家的支持程度也不太一样，例如，Android 硬解码 MediaCodec 只接受 AnnexB 格式的数据，而 Apple 的 VideoToolBox，只支持 avcC 的格式。所以这就需要我们从业者对两种格式都有一个了解。本章，我们先来介绍 AnnexB
2020年的一场疫情，让大家不得不呆在家里，远程工作不可避免，远程拜年成为潮流，5G时代的一个极大的需求正在被提前激发，音视频领域的大锅正在卡下来，你接不接这个锅？直播，终于接触这个话题，好好想想，完整的直播需要哪些流程？
和播放音频一样，采用生产者消费者模型。AvPacket入队，然后AvPacket出队伍解码。
我是英伟达深度学习解决方案架构师吴金钟，今天给大家介绍的是英伟达在直播场景中的解决方案。
Qzone的日均视频播放量已经突破了10亿，其中Android端的播放量在总播放量中的占比超过70%，相比年初，播放量的增长了超过10倍。视频下载是整个视频播放的基础，如果下载侧出问题，则会造成整个视频播放的失败，这就对我们的视频下载提出了非常高的要求。 基于此，我们将视频下载总结为"多快好省"四个方面，以下载成功率、首次缓冲时长和缓冲概率为主要的技术指标对视频下载进行优化。具体参数的优化结果见下表1，经过长时间的打磨，我们的视频下载模块的下载成功率已经达到了99.9%，视频的首次缓冲时长1.2秒，二次缓冲
常用的文件分辨率有 320*240 640*480 800*600 1280*720 1920x1080
i.MX8MM开发板采用四核Cortex-a53，单核cortex-m4，多达五个内核，主频高达，1.8GHz,开发板提供强大音视频处理能力，8路PDM接口，5路SAI接口，2路Speaker。支持H264,VP8格式的视频编码，H264,H265,VP8,VP9视频硬解码，最大支持1080P,并提供相关历程。
在写代码的过程中，经常需要利用ffmpeg进行h264编解码，ffmpeg默认是不支持h264编解码的，需要在编译ffmpeg时增加支持h264编解码功能模块。
音视频编码的标准由标准发展组织制定，主要两大组织：ISO（国际标准化组织和国际电工委员会）和ITU-T（国际电信联盟的电信标准化部门）
相信很多人和我一样，刚开始的时候都会很好奇，为什么h264可以实现这么强大的压缩比，要知道，1张1080p的YUV420就是3MB，想实现1秒钟30帧，千兆网就基本跑满了，这也太可怕了，基本上只有条件很好的局域网才能达到这个水平。但是h264的出现把这个数据量降到了百分之一，2个数量级，这实在太可怕了，技术的发展真的是强大。
在网络视频直播系统中常见编码器有H264/H265/VP8/VP9，其中H264和H265用的比较多，VP8和VP9用的比较少，H265的出现虽然时间短，但很多开发公司都一开始尝试使用H265作为直播编码的一种方式，但H264依然是主流的一种编码方式。下面给大家普及一下关于H264格式的知识。
FFmpeg是音视频领域很有名的一个库, 这里从两方面介绍, 一方面根据FFMPEG的命令行工具介绍, 介绍这些命令行工具的使用方法, 满足一般用户要求. 还有一方面从组件/库的划分来介绍, 介绍FFMPEG是有哪些组件和库组成, 每一个库的作用, 便于后续的自定义开发.
写代码的过程中，经常需要利用ffmpeg进行h264编解码，ffmpeg默认是不支持h264编解码的，需要在编译ffmpeg时增加支持h264编解码功能模块。
FuboTV 是一家美国流媒体电视服务公司，为美国、加拿大和西班牙的客户提供服务，主要专注于分发体育直播的频道。根据国家/地区的不同，Fubo 提供的频道可能包括访问 NFL、MLB、NBA、NHL、MLS、CPL 和国际足球，以及新闻、网络电视连续剧和电影。
Open Network Video Interface Forum，开放型网络视频接口论坛，以公开、开放的原则共同制定开放性行业标准。是一个提供开放网络视频接口的论坛组织。ONVIF规范描述了网络视频的模型、接口、数据类型以及数据交互的模式。可以让不同厂商所提供的产品，均可以通过统一的语言来进行交流，增加了协同性和灵活性。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
