https://lautung.com/categories/yin-shi-pin纸上得来终觉浅，绝知此事要躬行！Halo v2.27.2zh-cnhttps://lautung.com/upload/ChatGPT%20Image%202026%E5%B9%B47%E6%9C%8810%E6%97%A5%2002_45_40(1).webphttps://lautung.com/categories/yin-shi-pinSun, 15 Nov 2026 00:18:43 GMThttps://lautung.com/archives/streaming-protocols自适应流技术涉及HLS、DASH协议对比与DRM集成，ExoPlayer引擎适配方案。HLS采用m3u8清单组织.ts视频分片，适用于Apple生态及常规直播，需规避分片时长不一致导致的卡顿；DASH通过MPD XML文件实现更细的多视角分层控制，支持CMAF与HLS互播，调试需核对timescale和段号连续性；DRM通过内容保护协议（Widevine/PlayReady）控制访问时效与设备安全等级，密钥需严格分离防止泄露，需按终端能力配置不同加密策略并处理授权失效问题。ExoPlayer整合多协议播放，需注意生命周期管理（准备-播放-释放）、异步加载超大清单及自定义数据源对接，Media3包名迁移影响工程适配。技术选型需综合生态兼容度（HLS Apple更优、DASH多机种支持）、资源颗粒度（HLS分片冗余、DASH SegmentTemplate精准）、加密实施（DRM密钥分发与安全级别匹配）及引擎适配场景（多协议混播、后台持久化、实时流控制）等维度。]]>/archives/streaming-protocolsLTT音视频Wed, 16 Sep 2026 06:22:23 GMThttps://lautung.com/archives/YOd7s7TP流媒体服务器选型需结合业务场景、延迟要求、协议支持及运维成本综合评估。核心场景推荐：普通直播优先使用SRS，支持多协议转换与低延迟；安防场景ZLMediaKit在GB28181、RTSP协议支持上更优；内网轻量代理选择MediaMTX；低延迟互动直播推荐OvenMediaEngine或企业级Ant Media Server；大规模公网直播建议采用自建源站+CDN或云服务商方案。注意事项：HLS延迟较高不适用于强互动场景，WebRTC需额外重视带宽和服务器资源消耗，转码功能消耗CPU/GPU资源，带宽费用通常占运营成本最大比例，且浏览器不支持原生RTSP流播放需进行协议转换。选型需匹配业务发展阶段，新项目建议优先采用成熟开源方案如SRS或ZLMediaKit，企业级功能可考虑商业产品。]]>/archives/YOd7s7TPLTT音视频Wed, 16 Sep 2026 01:46:33 GMThttps://lautung.com/archives/0fp3b9Xz云直播选型需首先判断业务场景：国内普通直播、低延迟直播、互动直播等对应不同技术链路和成本结构。国内推荐腾讯云直播、阿里云视频直播、火山引擎视频直播；海外优先Cloudflare Stream、Amazon IVS。低延迟场景可选火山引擎RTM、阿里云超低延时直播等，需注意RTC与云直播的架构组合。计费核心为播放带宽、转码、存储，连麦直播需额外考虑RTC费用。技术团队较弱的业务建议全托管方案，自建仅适合有强定制需求且运维能力强的项目。选型时需结合地域分布、现有云生态、延迟需求等因素综合决策，海外业务需重点关注合规和全球分发效率。]]>/archives/0fp3b9XzLTT音视频Wed, 16 Sep 2026 01:46:28 GMThttps://lautung.com/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE11-H264%20I%E5%B8%A7P%E5%B8%A7B%E5%B8%A7%E5%8F%8A%E6%89%8B%E5%86%99%E7%BC%96%E7%A0%81%E5%99%A8文章概述H.264编码原理及实践步骤，重点解析三种关键帧特性：I帧作为独立参考帧，压缩率7与完整画面保存特性；P帧通过前后帧差值压缩（率20），依赖前序参考帧生成画面；B帧双向预测压缩率最高（达50），但需前后帧支持。帧内压缩采用DCT+JPEG策略，帧间压缩通过运动矢量匹配宏块并计算误差差值，编码流程包括图像分组、宏块搜索匹配、误差计算与压缩传输。实验显示B帧利用双向预测可节省80%空间，但解码复杂度高于P帧。手写编码器实现路径为：首步独立编码I帧（八分块DCT量化），后续P帧通过匹配前帧宏块并传输差值（运动矢量+误差图），B帧扩展双向预测。容器组装与优化方向涉及编码效率提升（压缩率）与性能优化（速度）。读者收益包括掌握视频编码核心算法与实战实现逻辑。]]>/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE11-H264%20I%E5%B8%A7P%E5%B8%A7B%E5%B8%A7%E5%8F%8A%E6%89%8B%E5%86%99%E7%BC%96%E7%A0%81%E5%99%A8LTT音视频Wed, 16 Sep 2026 01:46:23 GMThttps://lautung.com/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE10-%E8%A7%86%E9%A2%91%E6%B5%81H264%E7%A0%81%E6%B5%81%E5%88%86%E6%9E%90%E5%AE%9E%E6%88%98H.264编码采用分层结构，包含视频编码层（VCL）和网络提取层。VCL输出压缩数据序列化为NAL单元，每单元通过RBSP封装包含原始字节和咬尾0。起始码使用4字节（帧头）或3字节（非帧头），nal头包含 forbidden_bit、参考ID（NRI）及单元类型。NRI值为0时无需重构，高于0则需要参与解码且 loss影响随值增大而加重，隐藏位可检测传输错误。解码流程将NAL单元转换为RBSP后提取图像/序列参数集，通过pic_parameter_set_id和seq_parameter_set_id引用对应参数集。实例 ffmpeg命令可将视频编码为快预设的2000kbps H.264码流输出，输出文件hello.h264。]]>/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE10-%E8%A7%86%E9%A2%91%E6%B5%81H264%E7%A0%81%E6%B5%81%E5%88%86%E6%9E%90%E5%AE%9E%E6%88%98LTT音视频Wed, 16 Sep 2026 01:46:18 GMThttps://lautung.com/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE09-%E8%A7%86%E9%A2%91%E6%B5%81H264%E7%9A%84%E7%BB%84%E8%A3%85%E5%8E%9F%E7%90%86%E4%B8%8ENAL%E5%8D%95%E5%85%83H264编码通过分层结构优化视频传输与压缩效率。由宏观块作为基本单元构建图像序列，经片、片组、码流分层封装后输出，既支持网络流传输又可形成文件存储。传输层采用Annex-B标准，利用0x00 00 00 01或0x00 00 01起始码分隔NAL单元，解决传统流分割问题。编码层划分Network Abstraction Layer（NAL层）负责网络适配，将大帧拆解为适应TCP传输的独立单元；Video Coding Layer（VCL层）进行了基于MB宏块的压缩编码。这种结构不仅降低网络包丢失率，还提升压缩比达33%-50%。典型应用场景包括高清视频流传输与影视后期制作，通过标准化封装实现高效多平台兼容。]]>/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE09-%E8%A7%86%E9%A2%91%E6%B5%81H264%E7%9A%84%E7%BB%84%E8%A3%85%E5%8E%9F%E7%90%86%E4%B8%8ENAL%E5%8D%95%E5%85%83LTT音视频Wed, 16 Sep 2026 01:46:13 GMThttps://lautung.com/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE08-H264%E7%BC%96%E7%A0%81%E5%9F%BA%E7%A1%8004%E7%BC%96%E7%A0%81%E6%A0%87%E5%87%86%E4%B9%8B%E6%88%98H.264通过三大标准化组织合作完成技术妥协实现普及，而H.265因高专利费阻碍推广。VP9凭借开源模式在互联网应用中快速积累，但遭MPEG LA专利诉讼压制。AVS作为中国主导的标准通过行政推动在特定领域应用。技术层面H.265压缩效率提升300%，宏块尺寸扩大至64×64，但存在解码设备不足问题。VP9压缩效率仅提升50%却实现更快编码，CPU消耗更低。当前格局呈现H.265在企业级应用、VP9/AV1在互联网端的对抗，预计2022-2025年H.265将突破专利壁垒形成部分市场份额。未来AV1联盟已覆盖谷歌、苹果等主要浏览器厂商和芯片巨头，硬件加速支持完善，可能成为下一代主流标准，而H.265/HEVC通过技术优化与版权费调整或形成差异化应用。实际系统采用双编码共存策略，已实现H.265与VP9在云处理端的兼容校验，用户可根据设备成本与网络条件选择编码格式。]]>/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE08-H264%E7%BC%96%E7%A0%81%E5%9F%BA%E7%A1%8004%E7%BC%96%E7%A0%81%E6%A0%87%E5%87%86%E4%B9%8B%E6%88%98LTT音视频Wed, 16 Sep 2026 01:46:08 GMThttps://lautung.com/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE06-H264%E7%BC%96%E7%A0%81%E5%9F%BA%E7%A1%8002%E5%B8%A7%E9%97%B4%E9%A2%84%E6%B5%8BH.264帧间预测采用树状结构运动补偿，支持16×16、16×8、8×16、8×8等灵活分割模式，各子块独立计算运动矢量（MV）。亮度MV精度达1/4像素，通过六抽头滤波内插实现非整数坐标预测，色度精度为1/8像素。编码中MV和分割模式需额外比特标记，大尺寸分割适应平坦区域，小尺寸处理细节区域更高效。 多参考帧机制允许同时使用list0和list1两套参考序列（含短期动态列表），支持双向预测、单侧预测及直接模式。双向预测结合两个参考帧补偿，直接模式由已编码MV推导残差，减少传输开销。加权预测通过动态调整参考帧贡献度优化重建质量。 相比单参考帧的AVC，5帧多参考可降低5%-10%比特率，提升编码效率与恢复鲁棒性。技术演进从整数MV到亚像素精度，配合自适应分割和参考管理，显著增强了运动物体预测精度和码率控制能力，形成H.264相比前代编码的标准优势。]]>/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE06-H264%E7%BC%96%E7%A0%81%E5%9F%BA%E7%A1%8002%E5%B8%A7%E9%97%B4%E9%A2%84%E6%B5%8BLTT音视频Wed, 16 Sep 2026 01:45:57 GMThttps://lautung.com/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE05-H264%E7%BC%96%E7%A0%81%E5%9F%BA%E7%A1%8001%E5%B8%A7%E4%B8%8E%E5%9C%BA电视画面通过两次扫描形成，每帧包含两个场（25帧/秒对应50场/秒）。场编码与帧编码的选择依据画面运动特性：动态区域采用场编码提升压缩率，静态或低速区域使用帧编码增强空间冗余。计算机视频处理通常基于帧编码，无法兼容电视的隔行模式，需专用场编码软件适配电视传输。H.264标准创新采用MBAFF技术，以宏块为单位动态选择帧/场编码模式，通过场内运动补偿降低高频区域的码率（率达29.5%），配合宏块配对编码完整保留隔行特性。图像级自适应PAFF和宏块级MBAFF分别应用于全局运动估计与局部精细判决，在保证画面清晰度的同时有效降低存储传输需求。]]>/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE05-H264%E7%BC%96%E7%A0%81%E5%9F%BA%E7%A1%8001%E5%B8%A7%E4%B8%8E%E5%9C%BALTT音视频Wed, 16 Sep 2026 01:45:52 GMThttps://lautung.com/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE04-H264%E5%9F%BA%E6%9C%AC%E5%8E%9F%E7%90%86%E4%B8%8E%E7%BC%96%E8%A7%A3%E7%A0%81%E6%B5%81%E7%A8%8BH264通过帧内和帧间压缩高效降低视频数据冗余。核心原理：1）分组（GOP）将视频划分为关键帧（I帧）和参考前/后帧（P/B帧）；2）宏块划分（16x16或子块灵活调整）并计算运动矢量，通过帧间预测仅存储关键位移信息，使数据量减少至传统压缩的7%；3）帧内采用9种预测模式消除空间冗余；4）对预测残差进行DCT转换去除相关性，再通过CABAC熵编码实现无损压缩。技术优势体现在运动估计与补偿结合空间预测，显著降低编码数据量，如台球视频实例显示仅需7KB补偿数据即可恢复原始帧（独立压缩需50-60KB）。该算法平衡压缩效率与解码精度，成为主流视频格式基础。]]>/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE04-H264%E5%9F%BA%E6%9C%AC%E5%8E%9F%E7%90%86%E4%B8%8E%E7%BC%96%E8%A7%A3%E7%A0%81%E6%B5%81%E7%A8%8BLTT音视频Wed, 16 Sep 2026 01:45:46 GMThttps://lautung.com/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE03-%E9%9F%B3%E8%A7%86%E9%A2%91%E6%A0%BC%E5%BC%8F%E5%B0%81%E8%A3%85%E5%8E%9F%E7%90%86视频文件采用封装格式整合音视频流，常见格式如AVI、MKV对应不同容器标准。主流视频编码技术按数据量压缩与解码效率排序为H.264（广泛应用）、HEVC（高压缩比优化中）、VP9等。音频编码中MP3凭借早期普及形成基础应用场景，AAC通过多厂商协作提升压缩比与音质至MPEG-4标准，WMA则侧重微软生态的无损压缩方案。技术演进使音视频码流在同等数据量下实现更高分辨率呈现，封装与编码配合构成数字多媒体存储传输核心体系。]]>/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE03-%E9%9F%B3%E8%A7%86%E9%A2%91%E6%A0%BC%E5%BC%8F%E5%B0%81%E8%A3%85%E5%8E%9F%E7%90%86LTT音视频Wed, 16 Sep 2026 01:45:40 GMThttps://lautung.com/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE02-ffmpeg%E5%BC%95%E5%85%A5androidstudio基于Android工程集成FFmpeg的步骤包括：新建CMake工程后需将FFmpeg编译的头文件和动态库（如libavcodec.so/avutil.so等）分别置于src/main/jniLibs和app/src/main/cpp/include目录；在build.gradle中通过externalNativeBuild配置cmake参数指定abiFilters为armeabi-v7a；更新CMakeLists.txt实现多模块静态链接，并包含核心头文件；提供测试代码演示通过JNI调用C语言接口实现av{*}_version函数的版本验证功能。读者可通过此方案合法集成FFmpeg解码、编转等模块，并实现基础C/C++跨平台调用。]]>/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE02-ffmpeg%E5%BC%95%E5%85%A5androidstudioLTT音视频Wed, 16 Sep 2026 01:45:35 GMThttps://lautung.com/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE01-clang%E4%BA%A4%E5%8F%89%E7%BC%96%E8%AF%91%E6%9C%80%E6%96%B0ffmpeg基于mac系统使用NDK r20编译FFmpeg为armv7a架构Android库，需下载ffmpeg-4.2.1源码及对应NDK。配置时修改环境变量需确保SDK路径正确，并在ffmpeg目录创建安卓构建脚本。核心编译指令包括指定交叉编译架构、禁用静态库及调试工具、调整链接路径等链脚本参数。config.h头文件需通过sed命令显式启用多数学 float函数及系统相关定义，其中关键修改包括：启用 trunc、rint系列函数、修正inet_aton编译条件，同时禁用getenv函数。执行build.sh脚本后即可生成 uncompilled Android库文件，支持CMake和Makefile双向构建方式，需注意架构匹配与编译器路径指向。]]>/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE01-clang%E4%BA%A4%E5%8F%89%E7%BC%96%E8%AF%91%E6%9C%80%E6%96%B0ffmpegLTT音视频Wed, 16 Sep 2026 01:45:17 GMThttps://lautung.com/archives/yeBSjWXx视频防盗需采用综合策略：基础加密使用AES/HLS或DRM，客户端密钥可能通过内存、请求等途径泄露，但DRM能限制密钥暴露范围。平台需构建三层防护体系：内容加密（短期密钥+独立密钥）、访问控制（鉴权+设备限制）、泄露追踪（水印+日志）。技术无法彻底杜绝盗版，因观看后必然存在录屏可能。工程重点应放在提高盗取成本（加密复杂度、批量搬运难度）、缩小泄露影响（独立密钥、溯源能力），而非绝对安全。高价值内容需叠加硬件解密、数字取证等 Quotes方案，普通场景HLS加密+动态水印即可。核心目标为让盗版变得得不偿失，通过技术阻挠、权限管控、泄漏溯源与法律追责形成闭环治理。]]>/archives/yeBSjWXxLTT音视频Fri, 10 Jul 2026 17:35:58 GMThttps://lautung.com/archives/WJC36nbk浏览器内核指渲染引擎、JS引擎及配套能力。主流内核包括Blink（Chrome、Edge、Brave等）、WebKit（Safari、iOS）、Gecko（Firefox）。Chromium是开源框架，整合Blink（渲染）、V8（执行JS）、安全沙箱等项目，非单一内核概念。Firefox Quantum是对Gecko的现代化重构，提升性能但内核仍是Gecko。移动端Android WebView多基于Chromium/Blink，iOS因限制仍主推WebKit内核。需区分完整浏览器项目（Chromium）与内核组件（Blink），避免将自研框架（如Safari内核）与开源项目混淆。]]>/archives/WJC36nbkLTT音视频Sun, 5 Jul 2026 16:28:21 GMThttps://lautung.com/archives/Wxzt6Vit一、核心概念：容器、编码与协议 在深入架构之前，必须先理清三个核心概念的关系： 容器格式（封装格式） ：视频文件的“包装盒”，决定文件后缀名（如.mp4、.flv、.ts）。它规定如何将视频、音频、字幕等轨道打包在一起。 编码格式（压缩算法） ：视频内容的“压缩方式”，决定画质和文件大小。H.264]]>/archives/Wxzt6VitLTT音视频Mon, 29 Jun 2026 06:26:00 GMThttps://lautung.com/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE07-H264%E7%BC%96%E7%A0%81%E5%9F%BA%E7%A1%8003%E5%B8%A7%E5%86%85%E9%A2%84%E6%B5%8BH.264视频编码通过帧内预测优化压缩效率。亮度块采用4×4（9种预测模式）或16×16宏块（4种模式），色度块使用8×8预测（4种模式）。预测模式包括垂直、水平、DC平均及平面拟合，其中16×16块适合编码平坦区域以提高压缩率，4×4块针对细节丰富的区域提供更灵活的9种预测方式（如对角线、斜线及加权平均）。编码器依据相邻块预测模式的差异最小原则动态选择模式，解码器通过flag字段（1直接选用预测模式，0按保留剩余模式顺序递增判断）匹配当前块与候选块的预测模式，有效降低冗余数据量。该技术通过空间冗余预测替代完全独立编码，在保证视频质量的同时显著减少码流规模，特别适用于运动缓慢或纹理均质场景的编码优化。]]>/archives/%E9%9F%B3%E8%A7%86%E9%A2%91%E9%AB%98%E6%89%8B%E8%AF%BE07-H264%E7%BC%96%E7%A0%81%E5%9F%BA%E7%A1%8003%E5%B8%A7%E5%86%85%E9%A2%84%E6%B5%8BLTT音视频Mon, 23 Feb 2026 02:40:00 GMT