爱片闲串，爱钓鱼，爱中医，爱分享

这篇文章介绍了一个完整的售货柜视觉识别流水线的实现方案。主要内容包括： 整体架构设计：采用流水线方式将RTSP拉流、硬件解码、图像预处理和YOLO推理四个模块串联起来。 模块实现细节： StreamReader模块负责RTSP拉流和硬件解码，使用FFmpeg SDK实现，支持TCP传输和超时重连机制。 FrameProcessor模块处理图像预处理，包括裁剪、缩放和格式转换(YUV转RGB)。 关键技术点： 采用硬件解码(RKMPP)降低CPU负载 使用SwsContext实现高效的图像格式转换和缩放 多线

本文总结了FFmpeg性能优化的8个关键策略，按投入产出比排序： 优先使用流复制（-c copy）代替重新编码，适用于不改动视频内容的情况，速度可提升数十倍 充分利用硬件加速编解码（如NVIDIA NVENC、RK3588 RKMPP），性能提升3-10倍 合理配置多线程参数（-threads），平衡CPU核心利用率 减少不必要的像素格式转换（如YUV↔RGB），避免性能损耗 优化滤镜处理顺序，先裁剪/降采样再处理，减少计算量 优化I/O策略，使用管道代替临时文件，调整缓冲区大小 采用流水线架构，解码/处理

硬件加速编解码技术概览 本文系统介绍了三种主流硬件加速方案：NVIDIA NVENC/NVDEC、Intel QSV和RK3588 MPP。硬件编解码通过专用硬件模块实现，相比软件编解码具有速度快、功耗低、CPU占用少等优势。文章详细讲解了如何检测硬件加速支持、命令行使用方法，并重点阐述了RK3588 MPP的SDK开发流程，包括硬件解码、零拷贝技术和全硬件编码的实现。同时提供了验证硬件加速是否生效的实用方法，为嵌入式AIoT和实时视频处理项目提供了重要参考。

本文介绍了使用FFmpeg SDK进行视频编码、滤镜处理和完整转码流程的开发方法。主要内容包括： 编码流程：从创建编码器、设置参数到帧编码和flush处理 文件输出：使用libavformat写入封装格式文件 滤镜处理：构建滤镜图并实现视频处理链 完整转码：将解码、滤镜、编码和写入流程串联 文章提供了核心代码示例，涵盖了编码参数设置、时间戳处理、滤镜图初始化和转码循环结构。这些内容为开发者在自己的项目中集成FFmpeg功能提供了实用指导，帮助实现自定义的视频处理流程。

本文介绍了FFmpeg SDK开发入门知识，重点讲解核心结构体与视频解码流程。主要内容包括： FFmpeg核心库：libavformat（封装格式）、libavcodec（编解码）、libswscale（图像转换）等库的功能介绍 环境搭建：Windows/Linux/macOS下的安装方法及CMake配置 核心结构体详解： AVFormatContext：文件/流上下文 AVStream：单路流信息 AVCodecContext：编解码上下文 AVPacket：压缩数据包 AVFrame：解码后原始帧数据

本文介绍了HLS和DASH两种主流流媒体技术的原理和使用方法。HLS是苹果推出的协议，通过将视频切分为TS分片和m3u8索引文件实现流式播放，兼容性最好但延迟较高；DASH是国际标准协议，使用fMP4分片和mpd索引，灵活性更强但兼容性稍逊。文章详细说明了如何使用FFmpeg生成单码率和多码率的HLS/DASH文件，包括分片时长控制、加密、直播推流等场景。建议兼容性要求高的场景优先选择HLS，对灵活性要求高的选择DASH，或者两者同时生成。最后还介绍了在网页中通过hls.js和dash.js播放这两种格式的

做 IPC 摄像头、无人售货柜、安防监控，RTSP 拉流和录制是基本功。这篇讲清楚：怎么稳定拉流、怎么存成文件、怎么按时间分片、断线怎么自动重连、延迟怎么优化——全是实际项目里踩过的坑。大家好，我是黒漂技术佬。之前写 IPC 摄像头专栏的时候，很多人问 RTSP 拉流的问题：拉流花屏怎么办？怎么 24 小时录像？断网了怎么自动重连？录像文件太大怎么办？这些问题 FFmpeg 都能解决，但参数没配对的话，不是不稳定就是延迟高。这篇把我做售货柜项目积累的 RTSP 拉流录制经验全部分享出来。

本文详细介绍了使用FFmpeg进行视频抽帧的各种技巧，包括：基础截图（精确到毫秒）、按时间间隔抽帧、关键帧提取、精确时间段抽帧、缩略图网格生成等实用方法。特别针对计算机视觉数据集制作场景，提供了YOLO数据集抽帧的最佳实践建议，如合理设置间隔、去重处理、多分辨率采样等。文章还覆盖了RTSP流实时抽帧和常见问题解决方案，是视频处理和数据准备的高效指南。

音频处理核心指南：混音、降噪、音量调节与格式转换 本文系统介绍FFmpeg音频处理技术，涵盖基础概念、常用操作和实战技巧。主要内容包括： 音频基础：采样率、位深、声道数和码率等核心参数解析 格式转换：MP3、AAC、WAV等格式互转与视频音频提取 音量处理：基础调节、响度标准化和音量检测方法 降噪技术：传统频域降噪与AI降噪方案对比 混音拼接：背景音乐处理、多音频混合与连接技巧 进阶效果：淡入淡出、均衡器、压缩器和混响等特效应用 文章特别强调录音优化流程和音频处理原则，包括推荐使用AI降噪、避免多次转码损失

本文详细介绍了FFmpeg视频滤镜的使用方法，主要内容包括： 滤镜基础 滤镜是对视频帧进行处理的模块，以流水线方式工作 简单滤镜用-vf参数（单输入单输出） 复杂滤镜用-filter_complex参数（多输入多输出） 8个核心滤镜 scale：视频缩放 crop：画面裁剪 rotate/transpose：旋转 drawtext：添加文字水印 overlay：图片水印/画中画 fps：调整帧率 subtitles：添加字幕 eq：颜色调整 滤镜链使用 多个滤镜用逗号分隔顺序执行 执行顺序影响效果和性能（建

同一个视频，换封装格式（比如 MP4 转 MKV），**视频和音频本身没变，只是换了个箱子装**。这时候用 `-c copy` 直接复制流就行，速度极快。

什么叫 FFmpeg？Fast Forward Moving Picture Experts Group——翻译过来就是「快进的运动图像专家组」。诞生于 2000 年，至今 20 多年，是音视频领域的事实标准。

本文介绍了如何从零实现一个完整的WebRTC一对一视频通话系统。文章通过Node.js + Socket.IO搭建信令服务器，并完成前端页面的音视频采集、连接建立和通话控制功能。主要内容包括： 项目结构：包含信令服务器(server.js)和前端页面(index.html) 信令服务器实现：使用Socket.IO处理房间管理、用户加入/离开、Offer/Answer转发和ICE候选交换 前端功能：实现音视频采集、WebRTC连接建立、通话控制(静音/关闭摄像头/挂断)等完整通话流程 该项目完整演示了WebR

本文对比了WebRTC多人视频会议的三种架构方案：Mesh、SFU和MCU。Mesh架构采用P2P直连，适合2-4人小型会议，但客户端压力大；SFU通过服务器选择性转发视频流，适合5-50人场景，是当前主流方案；MCU将多路视频混合为一路，适合大型直播和弱终端场景，但服务器成本高。文章详细分析了各架构的优缺点、适用场景，并推荐了Mediasoup、Janus等主流开源SFU项目，建议根据实际需求选择合适的方案。

本文介绍了WebRTC信令服务器的设计与实现。WebRTC本身不处理信令，需要开发者自行实现SDP和ICE候选交换机制。信令服务器作为WebRTC系统的指挥中心，主要功能包括房间管理、成员状态维护、消息转发等。文章详细说明了信令消息类型（如房间操作、SDP交换、ICE候选转发等），推荐使用Socket.IO进行开发，并提供了Node.js实现的核心代码示例，包含房间管理、消息转发等关键功能。最后强调信令服务器设计时需注意房间模型、用户标识、状态同步等要点，为WebRTC应用提供可靠的信令通道。

本文介绍了WebRTC中的RTCDataChannel技术，重点探讨了其可靠与不可靠传输模式的特点及适用场景。文章首先解释了DataChannel的作用和优势，包括低延迟、P2P传输、多种数据格式支持等，并与WebSocket进行了对比。随后详细说明了创建和使用DataChannel的基本方法，包括数据发送接收和状态管理。 核心部分分析了四种传输模式：可靠有序（类似TCP）、可靠无序、不可靠有序和不可靠无序（类似UDP），并通过表格对比了不同场景下的最佳选择方案。文章还介绍了DataChannel的配置参数

WebRTC音视频编解码技术指南 本文介绍了WebRTC中常用的音视频编解码技术，重点对比了VP8、VP9、H.264和AV1视频编码以及Opus音频编码的特点和适用场景。文章首先解释了编解码的必要性，通过1080P视频原始数据量(720Mbps)与压缩后数据(2-4Mbps)的对比，展示了编解码技术的重要性。 在视频编码方面，VP8兼容性好但压缩率中等，VP9压缩率更高但计算复杂，H.264硬件支持广泛但有专利问题，AV1是未来方向但硬件支持有限。音频方面Opus是WebRTC默认选择，具有优异的音质和低

NAT穿透技术解析：STUN/TURN/ICE 本文深入讲解了WebRTC中实现P2P连接的关键技术——NAT穿透。主要内容包括： NAT原理：解释NAT的作用及四种类型（完全锥型、受限锥型、端口受限锥型、对称型），指出不同类型穿透难度差异 STUN技术：详述STUN服务器如何帮助发现公网地址，适用于锥型NAT环境 TURN技术：作为STUN的补充，通过中继转发解决对称型NAT等难以穿透的场景 ICE框架：整合STUN和TURN，自动选择最优连接路径，包含候选地址收集、交换、配对和连通性检查等步骤 实践建议

这篇文章详细介绍了 WebRTC 中 RTCPeerConnection 的建立流程，主要包括 SDP 协商和 ICE 候选交换两大核心机制。 摘要要点： RTCPeerConnection 负责 WebRTC 的媒体协商、网络穿透、安全传输和质量控制 SDP（会话描述协议）是文本格式的媒体配置描述，通过 Offer-Answer 模型进行协商 ICE 机制通过收集 host/srflx/relay 三种候选地址解决 NAT 穿透问题 完整连接流程：创建连接→交换 Offer/Answer→收集候选→建立

本文详细介绍了WebRTC中MediaStream和MediaStreamTrack的核心概念与操作。MediaStream代表包含多个轨道的媒体流，每个轨道（视频或音频）都是独立的MediaStreamTrack对象。 文章涵盖了以下关键内容： 基本概念：流与轨道的层级关系及轨道属性 流操作：创建流、获取/添加/移除轨道、克隆流等 轨道控制：开关轨道、停止轨道、动态调整参数 事件处理：轨道静音/结束、流状态变更等事件监听 实用技巧：替换轨道、合并分流、静音控制等常见场景实现 这些知识是WebRTC音视频处

本文详细介绍了WebRTC音视频采集的核心API getUserMedia 的使用方法和常见场景。主要内容包括：基础调用方式、视频参数控制（分辨率/帧率/摄像头切换）、音频参数配置（回声消除/降噪）、设备管理（枚举/切换设备）、屏幕共享实现、媒体轨道操作（开关/停止采集）以及权限处理。文章特别强调了实际应用中的关键细节，如设备兼容性处理、动态参数调整和不同场景下的最佳实践，为开发者提供了全面的音视频采集解决方案和技术指导。 （字数：148）

WebRTC入门指南：150字摘要 WebRTC是一项让浏览器和应用程序无需插件即可实现实时音视频通信的开源技术。它由Google发起并成为W3C标准，支持跨平台使用。核心技术包括： MediaStream（获取音视频流） RTCPeerConnection（建立P2P连接） RTCDataChannel（传输任意数据） 典型应用场景包括视频会议、屏幕共享和实时数据传输。实现流程涉及信令交换、SDP协商和ICE穿透。虽然功能强大，但面临NAT穿透、多人通信架构等挑战。入门示例仅需几行JavaScript即可

本文介绍了基于STM32+电磁锁+MQTT+IPC的无人售货柜完整开门闭环方案。作者针对原有纯RK3588主控方案的可靠性问题，新增了STM32独立门控模块，通过硬件架构设计、电路连接说明和核心代码逻辑，实现了双MQTT通道控制：STM32负责门锁指令执行和状态上报，RK3588主控专注于商品识别。文章详细阐述了MQTT通信协议设计、业务流程时序，并分享了继电器干扰和门磁抖动等实际调试中的解决方案。该方案显著提升了系统的可靠性，即使主控板故障也能确保门锁可控，同时实现了"用户扫码-开门-取货-识别-扣款"的

本文介绍了流媒体服务器的核心功能与选型建议，重点推荐国产开源的ZLMediaKit作为RTSP拉流转发解决方案。文章详细对比了主流流媒体服务器特性，提供了ZLMediaKit的Docker快速部署指南，并演示了如何通过API动态添加RTSP流源和实现Web端播放（HTTP-FLV/WebRTC）。最后强调转发不转码的性能优势，为无人售货柜等物联网场景提供低延迟视频监控方案。

很多做 IPC 开发的朋友，一开始都是从 RTSP 拉流入门的。直到有一天，对接的甲方发来一份文档：「摄像头需支持 GB28181 协议，接入市级视频监控平台」。你打开文档一看——SIP、Device ID、Catalog、Invite……完全不是熟悉的 ONVIF 那套 XML。这一篇，我就把 GB28181 的核心逻辑讲清楚

摘要： 本文详细记录了华天龙200万像素H.265 PoE摄像头的开箱配置与RTSP推流全流程。设备支持ONVIF Profile S和SD卡录像，通过IE兼容模式完成1080P编码设置（推荐H.265/2048Kbps），实测64GB卡可存储3天全天录像。RTSP地址格式为rtsp://IP:554/stream0/1，通过ffmpeg实现低延迟拉流（TCP传输）及转推RTMP服务器。该机型性价比突出（约100元），适合固定场景如无人货柜，但存在Web端依赖ActiveX、品控一般等缺点。完整链路验证了从

ONVIF与RTSP协议关系解析 本文通过比喻和分层结构，清晰解释了ONVIF和RTSP两种协议的本质区别与协作关系： 核心区别 ONVIF是控制协议（类似遥控器），用于设备发现、配置管理和功能控制 RTSP是流媒体协议（类似信号线），专门负责视频流传输 协议层级 ONVIF基于SOAP/XML Web服务，运行在HTTP层之上 RTSP作为信令协议控制RTP/UDP传输视频数据 实际应用 ONVIF标准化的GetStreamUri方法可获取不同品牌摄像头的RTSP地址 两种协议独立运行但相互配合，共同完成

你电脑上插的那个 USB 摄像头，和监控用的 IPC 摄像头，长得差不多，价格差好几倍。到底贵在哪？这一篇从零开始拆解：什么是 IPC、IPC 由哪些部件组成、SD 卡在里面干吗，以及为什么 IPC 不需要连电脑就能独立工作

SRS（Simple Realtime Server）** 是国产开源流媒体服务器，100% C++ 编写，单进程架构，性能碾压 nginx-rtmp。原生支持 RTMP、HLS、HTTP-FLV、WebRTC、SRT，而且有 Web 管理后台，看一眼就能上手

前几篇我们把视频和音频分别压缩好了。现在问题来了：这些数据怎么从主播的摄像头，传到几万观众的手机上？一根网线扛不住几万人同时拉流——流媒体协议就是解决"一对多实时分发"的

这篇文章深入浅出地解析了音频编码技术如何利用人耳特性实现高效压缩。主要内容包括： 原始PCM音频数据量大（CD音质1411kbps），编码通过心理声学模型去除人耳无法感知的部分。 关键压缩原理： 切除超出人耳频率范围的声音（20kHz以上） 利用掩蔽效应（强音盖弱音）和听觉阈值丢弃冗余信息 编码格式演进： MP3（1993年）实现10:1压缩但低码率表现差 AAC（1997年）在MP3一半码率下提供更好音质 Opus（2012年）成为开源全能方案 实践建议： 日常使用AAC 128kbps即可获得接近CD的

这一篇我们直奔主题——视频编码的核心原理。不讲数学公式推导，用你能听懂的人话把 **帧内预测、帧间预测、宏块、GOP、码率控制** 这些唬人概念全部拆干净

音视频压缩原理：从像素到播放的全过程 一张1920×1080的RGB图片原始大小约6MB，30fps视频每分钟数据量高达10.5GB。为减少体积，视频处理采用YUV色彩空间（4:2:0色度抽样可减半数据），音频通过采样率（如CD音质44.1kHz）和编码（如AAC）压缩。存储时，编码后的音视频流被打包到MP4等容器格式中。播放时经历解封装、解码、色彩转换等反向流程。整个过程利用人眼/耳特性进行智能压缩，使2小时电影仅需2GB，实现高效存储传输。 （共149字）

一、AAC编码概述AAC是高级音频编码（Advanced Audio Coding）的缩写，出现于1997年，最初是基于MPEG-2的音频编码技术，目的是取代MP3格式。2000年，MPEG-4标准出台，AAC重新集成了其它技术（PS,SBR），为区别于传统的MPEG-2 AAC，故含有SBR或PS特性的AAC又称为MPEG-4 AAC。AAC是新一代的音频有损压缩技术，它通过一些附加的编码技术（比如PS,SBR等），衍生出了LC-AAC,HE-AAC,HE-AACv2三种主要的编码。其中LC-AA

一、H264 概述H.264，通常也被称之为H.264/AVC（或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC）1. H.264视频编解码的意义H.264的出现就是为了创建比以前的视频压缩标准更高效的压缩标准，使用更好高效的视频压缩算法来压缩视频的占用空间，提高存储和传输的效率，在获得有效的压缩效果的同时，使得压缩过程引起的失真最小。MPEG-4 AVC和H.264 是目前较为主流的编码标准。主要定义了两方面的内容：视频数据压缩形式的编码表示和用重建视频信息的语法来描述编

一、TS 格式标准介绍TS是一种音视频封装格式，全称为MPEG2-TS。其中TS即"Transport Stream"的缩写。先简要介绍一下什么是MPEG2-TS：DVD的音视频格式为MPEG2-PS，全称是Program Stream。而TS的全称则是Transport Stream。MPEG2-PS主要应用于存储的具有固定时长的节目，如DVD电影，而MPEG-TS则主要应用于实时传送的节目，比如实时广播的电视节目。这两种格式的主要区别是什么呢？简单地打个比喻说，你将DVD上的VOB文件的前面

libyuv是Google开源的实现各种YUV与RGB之间相互转换、旋转、缩放的库。它是跨平台的，可在Windows、Linux、Mac、Android等操作系统。x86、x64、arm架构上进行编译执行，支持SSE、AVX、NEON等SIMD指令加速。以下说一下libyuv在Windows7VS2013 x64上的编译步骤及使用：1.从https://code.google.com/p/libyuv/source/checkout或者https://github.com/lemen...

YUV概述YUV，是一种颜色编码方法。常使用在各个影像处理组件中。 YUV在对照片或影片编码时，考虑到人类的感知能力，允许降低色度的带宽。YUV，分为三个分量：Y表示明亮度（Luminance或Luma），也就是灰度值； U(Cb)表示色度（Chrominance） V(Cr)表示浓度（Chroma）通常UV一起描述影像色彩和饱和度，用于指定像素的颜色。对于 YUV 图像来说，并不是每个像素点都需要包含了 Y、U、V 三个分量，根据不同的采样格式，可以每个 Y 分量都对应自己的 UV

从事之前从未接触过的Android音视频开发，主要涉及到USB摄像头调用、libyuv处理Nv21图像、直播推流等功能，对应的库有【UVCCamera】、【libyuv】等，刚接触没经验也没人带挺难搞的，而且网上资料很凌乱，所以，开此篇总结&汇总一下近期的研究，兴许可以帮助到别人，本人亦是新手，文中如有不正确的地方，欢迎指出点评。一、libyuv入门先简单说明一下，不管是Android手机的Camera，或是外接的UVCCamera（免驱摄像头），它们获取到的yuv图像格式都是nv21格式的

简介H.264是国际标准化组织（ISO）和国际电信联盟（ITU）共同提出的继MPEG4之后的新一代数字视频压缩格式。H.264是ITU-T以H.26x系列为名称命名的视频编解码技术标准之一。H.264是ITU-T的VCEG（视频编码专家组）和ISO/IEC的MPEG（活动图像编码专家组）的联合视频组（JVT：joint video team）开发的一个数字视频编码标准。该标准最早来自于ITU-T的称之为H.26L的项目的开发。H.26L这个名称虽然不太常见，但是一直被使用着。H.264是ITU-T以H.2