OpenSkeye的博客

​写这篇博客主要是为了给新入门的流媒体开发者解惑，现在看到各种开发者的需求：网页播放RTSP摄像机、微信播放RTSP摄像机、网页播放摄像机SDK输出的视频流、网页播放第三方流媒体平台输出的视频流、包括Github有一些所谓的H5RTSPPlayer，这些都有一个共同点，就是H.264+AAC进行RTMP推流，当然SkeyeWebPlayer除外，SkeyeWebPlayer开创性的支持在浏览器端采用H5直接播放器RTSP流，下载地址：SkeyeWebPlayer: 永久免费H5直播点播播放器，支持FLV

在之前的《SkeyeRTSPLive高效转码之SkeyeVideoDecoder高效解码》系列文章中我们已经将视频解码成了原始图像数据（YUV/RGB），然后根据不同的转码需求进行编码。如视频分辨率缩放，调整码率，多码率输出等；为了解决转码过程中编码高分辨率高质量或者高压缩率（如H265）耗时的问题，我们采用Nvidia硬件驱动编码器进行编码，以追求最高效率的转码和最低的推送延迟。SkeyeVideoEncoder基Nvidia独立显卡的硬件编码库SkeyeNvEncoder1. 接口声明如下：cla

在我之前写的一篇文章《SkeyeRTSPLive传统视频监控互联网+实现利器解决方案》中提到RTSP转RTMP的转流过程，简化流程就是通过SkeyeRTSPClient拉RTSP流，获取音视频编码数据，然后再通过SkeyeRTMP推出去，流程非常简单；然后再实际开发过程中，我们发现其实这个过程并没有想象中那么简单；首先，RTSP协议支持多种音视频编码格式，如音频支持AAC,G711，G726,等，视频支持H264，H625，MJPEG, MPEG等等各种格式，而SkeyeRTMPPusher推流只支持H26

在我之前写的一篇文章《SkeyeRTSPLive传统视频监控互联网+实现利器解决方案》中提到RTSP转RTMP的转流过程，简化流程就是通过SkeyeRTSPClient拉RTSP流，获取音视频编码数据，然后再通过SkeyeRTMPPusher推出去，流程非常简单；然后再实际开发过程中，我们发现其实这个过程并没有想象中那么简单；首先，RTSP协议支持多种音视频编码格式，如音频支持AAC,G711，G726,等，视频支持H264，H625，MJPEG, MPEG等等各种格式，而SkeyeRTMPPusher推流

在我之前写的一篇文章《SkeyeRTSPLive传统视频监控互联网+实现利器解决方案》中提到RTSP转RTMP的转流过程，简化流程就是通过SkeyeRTSPClient拉RTSP流，获取音视频编码数据，然后再通过SkeyeRTMPPusher推出去，流程非常简单；然后再实际开发过程中，我们发现其实这个过程并没有想象中那么简单；首先，RTSP协议支持多种音视频编码格式，如音频支持AAC,G711，G726,等，视频支持H264，H625，MJPEG, MPEG等等各种格式，而SkeyeRTMP推流只支持H26

随着互联网的发展，传统安防行业已不再满足于仅仅通过一台PC机器，或者一台NVR接入摄像机源进行录像和监控的基本要求，人们迫切的需要利用目前相当便利的网络环境，以便能实现随时随地的观看到适应各种网络环境和各种终端设备的低延时的音视频视频监控，录像取证和应急处理，而不再受到时间和地域的限制。同样，对于互联网服务，PC电脑也不再是唯一选择，智能手机、平板电脑、特定的移动终端等都是可选择的用户终端硬件方式；因此，我们需要一款能将安防协议，电视广播协议以及其他各种格式的流媒体协议接入到互联网上来，通过一种统一格式的

不久前刚实现SkeyeRTMPPusher扩展支持h265推送，当时在网上也查找了很多资料，发现都不尽详细，而官方也没有更新对HEVC(H265，后文统称HEVC)tag的支持，反正是走了不少弯路，当然，在广大网友以及ffmpeg代码的帮助下我最终实现了通过SkeyeRTMPPusher推送HEVC视频帧数据到SkeyeSMS，这里我将把实现过程详细的记录下来，供广大网友参考。 首先， RTMP头部信息封装并没有定义HEVC，我们采用CDN联盟的HEVC扩展标准，将HEVC的VideoTagHeader定

随着互联网以及科技水平的发展，对于互联网服务，PC不再是唯一选择，智能手机、平板电脑、特定的移动终端等都是可选择的用户终端硬件方式，因此，我们需要一款能将安防协议，电视广播协议以及其他各种格式的流媒体协议接入到互联网上来，通过一种统一格式的协议进行多平台多终端直播。RTMPLive流媒体直播软件（以下简称“RTMPLive”）将RTSP/RTP/RTMP/HTTP/UDP等协议的音视频数据进行拉取、转换，再转换成RTMP的方式推送到RTMP服务器/CDN等。以实现网页端无插件直播以及多平台多终端观看。R

不久前我们已经在RTMP推送端扩展支持了HEVC(H.265 后文统称H265)编码格式，但是，由于RTMP官方指定的协议格式已经不再更新，官方的播放器的Flash播放器并不支持H265格式的编码数据进行解码播放；现在，我们需要在播放器端解析RTMP流时对H265编码格式进行扩展支持。首先，我们可以通过扩展ffmpeg，让其支持拉H265封装的RTMP流进行解码播放，我们可以通过金山云对FFmepg的扩展支持H265来解决。然后，我们通过修改SkeyeRTMPClient的代码实现对H265 的支持，因

在之前两篇关于SkeyeRTMPClient扩展支持HEVC(H.265)解决方案的文章中，我们已经完成了对H265的支持，本文主要阐述将H26和H265支持兼容起来，实现不同视频编码格式的自适应兼容适配。1. 根据CodecId判断数据编码类型根据视频编码ID判断视频编码类型，如果视频编码ID==FlvCodeId_Hevc（12）,则判断视频编码格式为H265，反之则为H264（因为目前我们只支持这两种编码格式的视频推送），如下代码所示： parser_VideoTag *video_tag

在上一篇 SkeyeRTMPClient拉取RTMP流扩展支持HEVC(H.265)解决方案 中关于HEVCDecoderConfigurationRecord结构解析的讲解存在一些表述上不清楚的地方，本文为之续篇，重点对HEVC格式的MetaData结构的解析进行讲解。在SkeyeRTMPPusher扩展支持H265的解决方案讲述时。我们对Metadata结构进行过详解，大家可以回顾一下这篇文章RTMP推送扩展支持HEVC(H265)之Metadata结构填写详解，重点来了，因为正常情况下，我们只需要从

SkeyeRMS作为面向云端的录播服务器，以往的SkeyeRMS查找通常只能精确到M3U8列表，而不能实现精确到时间点的查询，为了能实现精确到点的查询，我将M3U8列表从新遍历一遍，重新生成一个精确到在关键位置开始和结束的切片文件（ts）的M3U8列表，然后返回，我们先不讨论这个方法效率如何，但是确实可以将精确度提高到切片文件单位级。精确查找流程如下：遍历本地（数据库）指定录像存储路径，找出在指定开始时间和结束时间范围内的M3U8列表，注意：这里找到的M3U8列表的区间是要小于开始时间，和大于结束时

SkeyePlayer播放器以其低延时播放RTSP、RTMP等流而闻名，而低延时播放除了低延时的拉流库以及高编解码效率外，视频图像的高速渲染也尤为重要；本篇以及系列文章主要讲解SkeyePlayer播放器的渲染引擎D3DRender，该渲染引擎支持基于GDI和D3D两种渲染方式，GDI方式也是我们熟知的windows图像绘制接口，普遍应用于win32以及MFC界面编程，以及图形元素的绘制；但是由于使用纯软的windows系统api接口进行绘制，其效率通常比较低，而D3D可以启用硬件加速，所以，通常其效率会

SkeyePlayer依靠D3DRender强大的渲染能力我们可以实现很多视频编辑功能，比如电子放大功能，本文将深入D3DRender渲染引擎库代码，重点讲述其如何采用surface离屏表面技术来实现渲染视频图像呈现，以实现在surface上做电子放大缩略图显示等功能。1. D3DRender初始化D3D创建设备首先，我们需要创建一个D3D9设备用于操作系统软硬件资源来为我们的视频渲染服务，这个代码很简单，按照Direct3D教程即可实现，如下代码所示： pD3D = Direct3DCreate9(

近期SkeyePlayer（windows）更新已全面支持H265的RTSP流的解码播放，这里就支持H265过程做简要介绍；一、 libSkeyeRTSPClient库已支持H265视频源的RTSP流的拉取和解析二、H265头解析H265和H264类似，不过其NAL type格式更多样化，除了SPS，PPS之外，还增加了VPS，下面就针对H265帧nal 头做简单分析；首先，看X265源码中的H265nal头格式定义：//H265 NAL type//this enum have been de

鉴于大家对于SkeyePlayer插件的使用还不太熟悉，特此写一篇插件的使用文档，供大家参考；SkeyePlayer插件有两种，一种是基于IE的ActiveX控件，一种是基于FireFox（也支持多浏览器）的npAPI插件；两种插件均包含源码，由于FireBreath框架生成代码比较多，npAPI插件只包含关键代码，后续会提供专门讲解FireBreath生成SkeyePlayer npAPI插件的文档，下面我们开始讲解两种插件如何使用。ActiveX OCX控件ActiveX控件使用MFC Acti

SkeyePlayer支持多路拉流播放，而拉流解码的过程需要占用系统资源，而我们都知道32位程序最多只能利用4G的内存，而现在动则8G，16G的内存空间是完全不能被利用的；所以，为了充分利用内存资源，我们准备将SkeyePlayer改成64位版本。新建64位编译平台所有依赖库编译成64位1> gpac库编译64位官网下载gpac源码，通过cmake生成对应的VS版本，然后编译64位平台即可；2> libSkeyeAACEncoder库编译64位3> ffmpeg编译6

测试发现，通过SkeyePlayer拉取网络摄像机的流, 其音频可能是G711，G726等，而写MP4或者转推RTMP等都不支持这些音频格式，那么我们就需要将其音频转码成AAC，可以使用libSkeyeAACEncoder库进行转码，然后写MP4或者推送；然而，在实际应用中，我们发现转码过程其实还是比较耗时的，它甚至会导致解码线程来不及从而使直播延时增大，所以，我们采用队列缓存+线程的方式来优化录像和抓图。实现如下：录像优化1> 开启录像 if (pThread->manuRec

不久之前我们对SkeyeRTMPClient库扩展支持了HEVC(H.265)，在后续的长期性能测试中，我们发现拉多路流时，会出现拉流播放一直都播不出来的问题，甚至有一定概率出现崩溃，经过长期的测试和排查，我们发现这是由于音视频数据发送比较频繁的时候出现的tcp粘包的问题，下面将详细讲述粘包问题的解决过程。1. SkeyeRTMPClient流接收流程SkeyeRTMPClient底层采用rtmp协议官方提供的librtmp库来实现rtmp流协议流程的连接建立，读取流数据，接收FLV数据组包分包等，然后

接上一篇[SkeyePlayer源码解析系列之录像写MP4]之续篇，我们来讲解一下关于H264编码格式中的一帧多nal(Network Abstract Layer, 即网络抽象层)，关于H264和NAL，这里引用一段话来科普一下：【转】 在H.264/AVC视频编码标准中，整个系统框架被分为了两个层面：视频编码层面（VCL）和网络抽象层面（NAL）。其中，前者负责有效表示视频数据的内容，而后者则负责格式化数据并提供头信息，以保证数据适合各种信道和存储介质上的传输。因此我们平时的每帧数据就是一个NAL单元

SkeyePlayer(Windows)中录像采用GPAC的MP4Box库来封装MP4，下面我将简单介绍MP4的封装调用流程和需要注意的点；一、GPAC库的编译，GPAC是跨平台的库，windows和linux都能很方便多编译，再次不做过多赘述，大家可去GPAC官网或者Github上下载；二、创建MP4bool SkeyeMP4Writer::CreateMP4File(char*filename,int flag){ SaveFile(); m_audiostartimestamp=-1;

概述libSkeyePlayer实现对RTSP、RTMP直播流进行实时采集和解码显示，稳定，高效，低延时；解码可采用intel硬件解码和软件解码两种方式，能实时进行录像和快照抓图，OSD叠加等功能。API接口函数定义 int SkeyePlayer_Init();函数说明：播放器初始化，播放器使用之前调用；参数说明： void SkeyePlayer_Release();函数说明：播放器资源释放，播放器不再使用以后调用；参数说明：int SkeyePlayer_OpenStrea

SkeyePlayer Windows端(下文简称：SkeyePlayer)播放器之前抓图代码主要通过OpenCV来实现，且数据格式转换的效率过于低下；故而在当时的代码中采用线程机制来解决抓图导致视频播放时卡顿的问题；而最新版的SkeyePlayer为了精简代码也为了提高抓图效率，我们采用ffmpeg进行抓图，为了保证视频播放的流畅性，线程机制我们仍然保留。采用ffmpeg进行抓图代码如下// 抓图函数实现int take_snapshot(char *file, int w, int h, uint

SkeyePlayer RTSP Windows播放器新增OSD字幕叠加接口方法，这个接口和码率信息显示接口方法类似，都是调用FFRender库的接口实现的多OSD叠加，下面讲解下该方法的调用和注意事项；OSD叠加方法声明如下：LIB_SkeyePLAYER_API int SkeyePlayer_ShowOSD(int channelId, int show, Skeye_PALYER_OSD osd);其中，channelId： 播放器通道ID，标识当前的播放器实例；show：标识是否显示OS

SkeyePlayer RTSP windows播放器支持D3D和GDI两种渲染方式，其中D3D支持格式如下： DISPLAY_FORMAT_YV12 DISPLAY_FORMAT_YUY2 DISPLAY_FORMAT_UYVY DISPLAY_FORMAT_A8R8G8B8 DISPLAY_FORMAT_X8R8G8B8 DISPLAY_FORMAT_RGB565 DISPLAY_FORMAT_RGB555 GDI支持格式如下： DISPLAY_FORMAT_RGB

经常我们会在流媒体推送端提到“数据回调”这个词，在多媒体编程中，我们会比较常用到线程数据回调，在SkeyeClient管理类代码中用到了两个数据回调函数，分别是DShow原始音视频数据采集回调函数和SkeyeRTSPClient网络接收线程中回调音视频编码数据回调函数；虽然两者采集到的数据不同，但是我们的用途是一致的，都是用来推送，所以我们通常会用一个数据回调管理函数来进行统一管理。int CSourceManager::SourceManager(int _channelId, int *_channe

在近期发布的SkeyeLive多窗口版本中，由于界面的局限性，选择性的将本地采集的音视频参数设置在界面上剔除掉了（暂时还没想好放在哪里，后续版本会在界面调整后添加），大家可以查看SkeyeLive源码中的StartDSCapture函数的参数设置代码进行相应设置；也应近期SkeyeSMS流媒体服务器群（QQ群：102644504，欢迎大家进群交流，任何技术问题，在所知的范围内都能给予解答）中大家提到的参数设置的错误提示以及参数该如何设置的问题，下面我将就参数设置的具体细节和代码关联做详细介绍。一、查看设备

SkeyeExPlayer for Windows是基于ffmpeg进行开发的全功能播放器，开发过程中参考了很多开源的播放器，诸如vlc和ffplay等，其中最强大的莫过于vlc，但是鉴于vlc框架过于庞大而其中仍存在诸多问题而舍弃了，而其他的更倾向于演示demo，只能提供部分借鉴意义；故而，SkeyeExPlayer 一贯秉承Skeye系列小而精，接口简单功能强大的宗旨从新设计了一套框架，该套框架能适应多线程调用以及多个播放实例同时运行，和SkeyePlayer一样Skeye; 当然，在此也郑重的感谢各

下面我们来讲解一下关于SkeyeExPlayer接口的调用，主要分为C++和C#两种语言，C++也可以基于VC和QT进行开发，C++以VC MFC框架为例进行讲解，C#以Winform框架为例进行讲解。VC开发SkeyeExPlayer首先建一个基于MFC Dialog的工程，取名叫SkeyeExPlayer，关于界面逻辑的处理过程就不做过多赘述了，大家有兴趣的可以去看SkeyeExPlayer项目代码；下面我们讲解一下SkeyeExPlayer的调用流程：(1) 打开一个流或文件进行播放通过S

SkeyeExPlayer（windows）接口说明如下：SkeyeExPlayer_Open说明：打开一个媒体流或者媒体文件进行播放，同时返回一个 player 对象指针参数说明：fileUrl - 文件路径（可以是网络流媒体的 URL）hWnd - Win32 的窗口句柄/其他平台渲染显示设备句柄 返回值： Easy_PlayerPro_Handle 指针类型，指向 SkeyeExPlayer 对象句柄声明如下：SkeyeExPlayer_Handle SkeyeE

SkeyeExPlayer主要基于ffmpeg进行开发，在SkeyeExPlayer开发过程中，曾遇到一个相对比较棘手的问题，该问题一般在播放不是很标准的流或者网络情况较差，容易出现丢帧的情况特别容易出现；基本表象在，播放一段时间程序会弹出错误或者崩溃，查代码逻辑根本无法查起，且不易重现（比如，我现在就想重现，也未能重现出来–！后面补上），不过在播放没有音频的rtsp流的时候比较容易出现，报错定位output.c源文件中，应该是字符串格式化输出的时候出错，经过排查，定位到ffmpeg的日志输出，为了便于查

在讲解SkeyeExPlayer快放慢放之前，我们首先要讲解下SkeyeExPlayer的音视频同步机制，我们采用视频同步音频的方式进行时间戳同步，无音频情况下视频自同步；视频自同步的情况比较简单这里就不做描述，下面我们着重讲解下音视频同步存在时的快放慢放并如何保持音视频同步。1.音视频同步原理首先，音频解码后获取到的PCM原始数据使用waveout直接进行播放，并记录当前播放时间戳，音频在任何时候都是正常播放，不做同步操作；然后，视频时间戳来同步音频时间戳： DWORD

本篇文章基于上一篇SkeyeExPlayer(Windows)开发系列之采用ffmpeg进行录像进行补充，测试发现录像的切片除了第一个时间戳是正常的，其他的初始时间戳均不正常而且是之前切片的时间长度的总和；更有甚者很长一段时间的录像都是黑屏无法播放的，为了解决这个问题，我们需要将时间戳进行修正。经过分析，初始时间戳是ffmpeg读取网络流自带的时间戳，在过程中读取流进行录像，那么势必初始的时间戳需要进行减掉，执行过程如下：首先，申请几个变量用以记录每次开始录像时的开始音视频时间戳，以及音视频是否进行重

在SkeyeExPlayer的开发过程中，经测试发现ffmpeg的读取网络流以及网络数据的接口都有较大概率出现阻塞的问题，ffmpeg也提供了设置阻塞回调或者设置超时等方式来跳出阻塞而不会导致接口永久卡住；而在某些时候，比如，网络断开时间过长的时候，这个时候阻塞回调将不在有用而且阻塞的接口也不再返回数据，出现"永久性"假死的情况，针对这些问题，本文将对其处理方式进行一一讲解。1.播放器结束时接口导致线程卡住针对该问题，我们通常可以在ffmpeg的阻塞回调函数中设置退出标志来解决，如下代码所示： //播

这篇和ffmpeg进行截图类似，不过省略掉编码的过程，从网络上或者文件读取的数据为编码后的数据，直接进行写文件即可，本文以写MP4文件为例进行讲解。1.创建线程执行开启录像 player->record_duration = duration*60; player->record_piece_id = 0; player->record_time = 0.0f; memset(player->record_path, 0, sizeof(MAX_PATH_LENGTH));

下面我们讲解下SkeyeExPlayer的截图功能，截图原理就是将YUV/RGB原始数据压缩成jpg或者png等格式（当然bmp格式是不需要压缩的），然后存储成文件的过程；我们以jpg格式为例进行讲解；一般情况下可以使用libjpeg库进行jpeg格式压缩，在不使用libjpeg的情况下，可以使用ffmpeg（内部也集成了libjpeg库）提供的接口进行压缩并写文件，这个方式也普遍适用于写MP4或者其他文件，下面我们讲解下ffmpeg进行截图的流程。1.数据源转换 // init ffmpeg

SkeyeExPlayer(Windows)经过为期一个月的开发已经基本完成，虽然目前仍存在一些小问题，但是总体功能还是趋于比较稳定和强大的，下面对其功能和应用场景做简要介绍。一 SkeyeExPlayer功能介绍Windows平台版本界面如下图所示：如上截图SkeyeExPlayer目前已支持 SkeyeExPlayer RTSP/RTMP/HLS/HTTP全功能流媒体播放器开发计划中罗列的绝大部分功能，诸如大部分流媒体和媒体文件的支持，单帧播放，快进和慢放，抓图，录像（支持分片）等功能；O

目前OpenSKEYE团队准备推出一款全平台的面向多种流和媒体的全能播放器SkeyeExPlayer，下面列出SkeyeExPlayer(for Windows)的开发计划；SkeyeExPlayer开发将满足以下需求：.支持rtsp/ rtmp/ hls/ http协议，支持大部分媒体文件的播放. 视频按比例显示，扩展显示（充满整个窗口区域），全屏显示.视频osd叠加功能，加载台标，字幕，画中画缩放，美化渲染，特效等. 支持视频截图保存.网络直播流支持本地视频录像保存.支持音量调整

鉴于广大码友对上一篇文章SkeyeRTMPPusher推送RTMP扩展支持HEVC(H265)的Metadata数据结构还存在不清楚的地方，这里对RTMP推送Metadata的结构进行详解。首先， 我们先讲解下 H.264/AVC metadata 语法，方便大家理解，这相关的文章大家在网上很容易找到，如果大家比较熟悉可以跳过；参考：《ISO/IEC 14496-15 NAL unit structured video》AVCDecoderConfigurationRecord结构：（最小长度7字节）

不久前刚实现SkeyeRTMPPusher扩展支持h265推送，当时在网上也查找了很多资料，发现都不尽详细，而官方也没有更新对HEVC(H265，后文统称HEVC)tag的支持，反正是走了不少弯路，当然，在广大网友以及ffmpeg代码的帮助下我最终实现了通过SkeyeRTMPPusher推送HEVC视频帧数据到SkeyeSMS，这里我将把实现过程详细的记录下来，供广大网友参考。 首先， RTMP头部信息封装并没有定义HEVC，我们采用CDN联盟的HEVC扩展标准，将HEVC的VideoTagHeader定