我们在做Windows平台Unity播放RTMP或RTSP的时候，遇到这样的问题，比如展会、安防监控等场景下，需要同时播放多路RTMP或RTSP流，这样对设备性能，提出来更高的要求。
本文基于之前的Demo添加了FFmpeg使用MediaCodec来硬解码的方式，包括解码出buffer再利用OpenGL进行渲染上屏和直接解码到Surface然后上屏两种方式
视频编解码硬件方案最早是在嵌入式领域中广泛存在，如采用DSP,FPGA，ASIC等，用来弥补嵌入式系统CPU等资源能力不足问题，但随着视频分辨率越来越高（从CIF经历720P，1080P发展到4K，8K），编码算法越来越复杂（从mpeg2经历h264,发展到h265）,PC的软件规模也越来越庞大，视频应用也越来也丰富，单独靠CPU来编解码已经显得勉为其难，一种集成在显卡中gpu用来参与编解码工作已经成为主流。
在手机视频播放方面，基于专用芯片的硬解码由于速度快、功耗低，成为了手机视频解码的首选方案。但是，硬解码芯片部署周期长、迭代速度慢，相当程度上制约了手机视频编码技术的更新换代速度。近年来，随着智能手机通用处理能力的不断增强，软件解码由于部署便捷，逐渐开始流行起来。那么，目前硬解码相对于软解码的功耗优势还有多大呢？带着这个问题，我们选择了几款典型手机测试了H.264/AVC硬解、H.264/AVC软解、H.265/HEVC硬解、H.265/HEVC软解和AVS2软解码之间的功耗差异，发现一个重要现象：硬解码相对于软解码的功耗优势正在逐步丧失，近几年生产的智能手机在主流的720P（1280x720）及更小分辨率视频上硬解和软解的功耗差异已经很小。这意味着：手机端视频编码技术的更新迭代速度将会大大加快。下面具体描述测试过程和结果。
我们在对接开发者的时候，遇到这样的诉求：除了正常的RTMP、RTSP直播播放外，有些硬件设备输出编码后（H.264/H.265）的数据，比如无人机或类似硬件产品，回调出来的H.264/H.265数据，除了正常转推到RTMP、轻量级RTSP服务或GB28181外，还需要本地预览甚至重新对数据做二次处理，基于这样的场景诉求，我们开发了外部编码后数据实时预览播放模块。
Webrtc使用是RTP分装码流，跟视频监控领域，IPTV领域，会议电视一样都是RTP承载媒体流，只不过webrtc信令遵守ICE框架，走自定义信令，IPTV领域走RTSP信令，视频监控走GB28181或者onvif信令，会议电视走h323或SIP协议。但webrtc 不能像传统IPTV和视频监控，会议电视一样可以直接抓包导流播放，因为webrtc的RTP流做了以下工作：
不知道大家小时候是否玩过一种动画小人书，连续翻动的时候，小人书的画面就会变成一个动画，类似现在的gif格式图片。
6.支持S3C6410 H264、H263、VC-1/WMV3、Mpeg4 480P 30fps播放
本文将介绍 RTSP H264/HEVC 裸流如何于网页前端播放。涉及 WebSocket 代理发送流数据， Wasm 前端解码等。
时至今日，短视频App可谓是如日中天，一片兴兴向荣。随着短视频的兴起，音视频开发也越来越受到重视，但是由于音视频开发涉及知识面比较广，入门门槛相对较高，让许许多多开发者望而生畏。
/* * 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
导语 |众所周知，在动图场景中， GIF 一直是应用得最广泛的技术，然而 GIF 文件体积太大的劣势，导致了一些诸如客户端 GIF 加载慢、服务器占用带宽大等问题。那么，在 GIF 占比如此高的今天，有没有一些更合适的动图格式，既能减小文件体积和服务器带宽，又能在客户端有不俗的性能表现？本文将介绍信息流场景下一套 GIF 体验提升的通用解决方案，该方案已经在腾讯看点内短内容场景中落地。 问题背景 看点短内容是看点信息流的重要内容，短内容有些类似微博段子，内容大多以娱乐、搞笑为主，因此有大量的 GIF 动图
默认，chrome只会打开错误级别，很多调试日志都不输出。在启动时，通过命令行打开日志级别即可。
本文主要介绍了如何在移动端GPU上对视频进行高效的编码与解码，通过对比多种编码方式、使用GPU对视频进行硬件加速、利用GPU对视频进行实时处理、以及对视频进行高效压缩与解码，最终实现了在移动端GPU上对视频进行高效编码与解码的解决方案。
『音视频技术开发周刊』由LiveVideoStack团队出品，专注在音视频技术领域，纵览相关技术领域的干货和新闻投稿，每周一期。点击『阅读原文』，浏览第92期内容，祝您阅读愉快。 架构 从通信到AI FreeSWITCH与WebRTC FreeSWITCH是一个开源的软交换平台，具有模块化结构，支持包括WebRTC在内的多种互通互联。本文来自FreeSWITCH 中文社区创始人杜金房在LiveVideoStack线上交流分享中的演讲，详细介绍了FreeSWITCH的功能特性、架构以及现状。 如何利用免版
看着精彩的德甲赛事，突然裁判一声口哨，球赛断掉了，屏幕开始自动播放“吃麦趣鸡盒，看德甲比赛”的视频广告
是的，一般场景是用不到的，我们在开发这块前几年已经开发了非常稳定的RTMP、RTSP直播播放模块，不过也遇到这样的场景，部分设备输出编码后（视频：H.264/H.265，音频：AAC/PCMA/PCMU）的数据，比如无人机或部分智能硬件设备，回调出来的H.264/H.265数据，除了想转推到RTMP、轻量级RTSP服务或GB28181外，还需要本地预览甚至对数据做二次处理（视频分析、实时水印字符叠加等，然后二次编码），基于这样的场景诉求，我们开发了Android平台外部编码数据实时预览播放模块。
3.1 FFmpeg本身支持一些编码、封装与协议，但是支持的依然有限，有些是因为licence，有些是因为相对来说比较大，FFmpeg所做的是提供一套基础的框架，而这些编码、封装与协议可以作为一个FFmpeg的模块挂在FFmpeg中，这些模块以第三方的外部库的方式提供支持，可以通过FFmpeg的源码的configure进行查看FFmpeg默认支持的编码、封装与协议的支持，不支持的可以再configure –help的时候查看所支持的第三方外部库，可以通过对应的参数选项进行支持：
前一篇《webrtc方案漫谈》我们分析了webrtc的方案特点，根据实际的应用场景我们需要对webrtc native代码进行定制开发，下面对webrtc常规需求进行定制。
ffmpeg -i mp4_sample.mp4 -vcodec copy -an -bsf:v h264_mp4toannexb raw.h264
16年壮观的直播百团大战相信大家历历在目，至19年初所剩无几的直播寡头，来去如风的直播战场，离不开背后强大的直播技术支撑，本文通过直播基础技术介绍、剖析企鹅电竞直播构架、关键技术、常见问题排查、带领大家了解直播技术细节。 直播基础技术扫盲 分辨率 分辨率是度量位图图像内数据量多少的一个参数。通常表示成每英寸像素（Pixel per inch, ppi）和每英寸点（Dot per inch, dpi），包含的数据越多，图形文件的长度就越大，也能表现更丰富的细节。但更大的文件需要耗用更多的计算机资源，更多的内
Android的视频相关的开发，大概一直是整个Android生态，以及Android API中，最为分裂以及兼容性问题最为突出的一部分。摄像头，以及视频编码相关的API，Google一直对这方面的控制力非常差，导致不同厂商对这两个API的实现有不少差异，而且从API的设计来看，一直以来优化也相当有限，甚至有人认为这是“Android上最难用的API之一” 以微信为例，我们录制一个540p的mp4文件，对于Android来说，大体上是遵循这么一个流程： ---- ---- 大体上就是从摄像头输出的YUV帧
我们在做GB28181设备对接模块和RTMP直播推送模块的时候，遇到这样的技术需求，设备（如执法记录仪）侧除了采集传统的摄像头外，还需要对接比如大疆等第三方数据源，确保按照GB28181规范和RTMP协议规范，接入到国标平台侧和RTMP服务，除了正常的接入需求外，还需要对第三方数据源回调过来的编码后视频、音频数据实时预览和播放。
本例实现，将输入文件中的视频流和音频流分离出来，保存为单独的文件，所保存的文件是不含封装格式的裸流文件。
视频采集在苹果爸爸的系统平台中是统一的#import <AVFoundation/AVFoundation.h>这个基础库。主要就是使用
Application->Assembly name，大牛直播SDK按照APP名称授权，未授权版本，此处请改成“SmartPlayer”，如需授权，可直接联系商务；
📷 『音视频技术开发周刊』由LiveVideoStack团队出品，专注在音视频技术领域，纵览相关技术领域的干货和新闻投稿，每周一期。 架构 FFmpeg Maintainer赵军：FFmpeg关键组件与硬件加速 本文来自FFmpeg Maintainer赵军在LiveVideoStackCon 2018热身分享，并由LiveVideoStack整理而成。在分享中，赵军介绍了FFmpeg的历史、关键组件，并介绍了英特尔平台上的多种FFmpeg硬件加速方式。 WebRTC点对点通讯架构设计 虽然几乎所有人都
2015年，我们在做移动单兵应急指挥项目的时候，推送端采用了RTMP方案，这在当时算是介入RTMP比较早的了，RTMP推送模块做好以后，我们找了市面上VLC还有Vitamio，来测试整体延迟，实际效果真的不尽人意，大家知道，应急指挥系统，除了稳定性外，对延迟有很高的要求，几秒钟（>3-5秒）的延迟，是我们接受不了的，VLC之类播放器，虽然功能庞大，点播体验可满足大多场景诉求，直播场景确实不尽人意。
在线直播可以说从去年开始变成了一个火爆的创业领域，一下子出来了很多做视频直播的公司。但说实话这方面的技术书籍实在是非常的少，网上的资料也很零散，所以我决定写一些列介绍视频技术的文章。今天这篇文章先对视频技术中的基础概念做一些简单的总结。
在刚提出4K视频的时候，大多数人都觉得没有必要，4K的出现，意味着更高的硬件规格和传输要求，1080P看的很爽、很清晰，完全满足了日常的需求。随着电视的尺寸越来越大，原本1080P成像已经无法满足人们对于细节的极致追求，4K视频不仅成像更细腻，在细节处理上优势也非常明显，颜色也更亮丽、饱满，逼真，给人身临其境的感觉。4K视频具有高分辨率、宽色域、高动态范围等优势，随着5G技术和H.265(HEVC)编码标准的出炉，4K视频直播迎来了曙光。
因为工作原因，接触编解码也有一段时间了。AVC，HEVC，大大小小的功能都也接触了一些，关于编解码的原理的书和文章自己一直在看。从入门到略懂，感觉有些零零碎碎，或不完整，似乎串不成体系。有些小功能，知道是知道，并不知道它的意义和作用，时间一长也会慢慢忘记。 反思了一下，或许很多东西，还是需要自己动手做一遍，会理解的更深更透彻一些，就像费曼学习法，你能讲出来，才说明懂了，这个也一样，你能把功能实现出来，才说明你真的明白了里面的流程和逻辑。于是乎，在今年过年期间，突然萌生出了写一个解码器的想法，而且一萌生就一直压不住了，一直想赶快动键盘写起来。 其实目前市面上开源好用的解码器有不少，像ffmpeg，x264等等。自己这个工程，应该就是单纯的一个学习工程吧，估计最后再怎么优化也达不到这些大名鼎鼎的工程的效果和功能，但是那又怎么样呢，过程和经历也很棒，不是吗？ 刚开始的时候是想写过一个编码器的，思考了一下之后很快就放弃了，我目前的想法只是想熟悉协议，并不是侧重于编码算法，相比之下，编写一个解码器所需要的的知识正是我所需要的。 这就成了这一系列文章的的起因了，算是自己一边写代码，一边写总结吧。 虽说是从“零”开始，但是编解码的基础知识还是要有一些储备的，我会在每一章里对解码所涉及到的知识点做一个介绍和讲解，但是太零碎的，就不会一一说明了。如果知识点太大，可能会单独写一篇来总结。
这几篇文章内容联系紧密，但放在一篇文章里内容太长，遂作拆分。章节号不作调整。基于FFmpeg 4.1版本。
对于720P分辨率，深度为8的一幅图片的数据量为：1280*720*8(位)，如果视频帧率为15，那一秒钟的数据量为：
Android端的视频相关的开发，大概一直是整个Android生态，以及Android API中，最为分裂以及兼容性问题最为突出的一部分。摄像头，以及视频编码相关的API，Google一直对这方面的控制力非常差，导致不同厂商对这两个API的实现有不少差异，而且从API的设计来看，一直以来优化也相当有限，甚至有人认为这是“Android上最难用的API之一”
先从opencv（2.4.10版本）采集回来摄像头的图像，是一帧一帧的 每一帧图像是一个矩阵，opencv中的mat 数据结构。
本节重点讲解了 H.264 编码以及 AAC 编码，在对其进行讲解前先介绍了视频编码的实现原理。
在《选择最新 Chromium，支持 H264 / H265》一文中，记录了我通过升级 Chromium 版本解决了 H264 / H265 视频支持难题。然而难题接踵而至，这次的难题是 MPEG TS 流的支持。
我们在做Windows平台RTMP和RTSP播放模块对接的时候，有开发者需要在wpf下调用，如果要在wpf下使用，只需要参考C#的对接demo即可，唯一不同的是，视频流数据显示的话，要么通过控件模式，要么可以让RTMP、RTSP播放模块回调rgb数据上来，在wpf直接绘制即可。
影音、游戏-云VR解决方案 ： 支持内容云端存储，基于高速网络+点量云传输技术，用户只需一个终端眼镜。拿起眼镜，即可实现即点即玩；摆脱线缆束缚，云端毫秒响应；升级用户体验，做到了内容低延迟、观感无眩晕。 云VR解决方案包括VR客户端APP软件、云端管理系统、GPU流服务系统以及同屏软件这几部分。
format，这个是官方h264协议文档中规定的格式，所以它是大多数编码器默认的编码后的输出格式。它的基本数据单位为NAL单元，简称NALU`（Network
首先，为什么要用NDK来做，因为自己之前就已经实现过RTMP推流、RTMP播放、RTSP转码等等各种c++实现的流媒体项目，有很成熟的代码模块。既然Android有NDK，可以JNI的方式复用之前的成熟代码，大大拓展和加快项目实现，那为什么不这样去做呢。和其他平台一样，要实现采集摄像头推送直播流，需要实现以下几点
这里使用VLC播放器,下载VLC 开始播放,点击[媒体]->[流]->[网络] 输入刚刚推流的地址。然后选在下方的播放。
FFmpeg是音视频领域很有名的一个库, 这里从两方面介绍, 一方面根据FFMPEG的命令行工具介绍, 介绍这些命令行工具的使用方法, 满足一般用户要求. 还有一方面从组件/库的划分来介绍, 介绍FFMPEG是有哪些组件和库组成, 每一个库的作用, 便于后续的自定义开发.
C++实现RTMP协议发送H.264编码及AAC编码的音视频 RTMP（Real Time Messaging Protocol）是专门用来传输音视频数据的流媒体协议，最初由Macromedia 公司创建，后来归Adobe公司所有，是一种私有协议，主要用来联系Flash Player和RtmpServer，如FMS, Red5, crtmpserver等。RTMP协议可用于实现直播、点播应用，通过FMLE（Flash Media Live Encoder）推送音视频数据至RtmpServer，可实现摄像
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的主要思路和关键点，以期对需要这方面技术的朋友有所帮助。
文章目录 一、通过此文可以得到什么 二、实现思路 三、实现效果 四、实现源代码 一、通过此文可以得到什么 通过此练习： 1、知道了如何计算一个音频和视频的播放时间； 2、知道了音视频解码的思路的大体流程，之后无非就是在这个流程上进行扩充细节； 3、知道了如何通过C语言或者C++编程语言结合ffmpeg拿到一些音视频的关键信息，例如：帧率等； 二、实现思路 📷 三、实现效果 zhenghui@zh-pc:/data/project/VSCProject/ffmpegStudy$ make make all m
博客：https://www.mintimate.cn 腾讯云社区：https://cloud.tencent.com/developer/user/7704194
在视频编码中，延迟是一个常见的问题。对于实时性要求较高的应用（如视频直播、视频会议等），延迟问题尤为重要。本文将重点讲解FFmpeg中H264和H265编码器的延迟问题，以及如何优化和降低编码延迟。
在日常的音视频开发中，我们经常使用FFmpeg，因为它确实好用呀，囊括了各种功能！但是有个很严重的问题，如果是编译在Android和IOS上使用，会造成APP的包很大。可以看我编译的FFmpeg在Android上的应用程式。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
