整理归纳写过的WebRTC系列研究文章。本系列文章专注WebRTC底层技术研究。 版权声明：本系列文章全部原创。欢迎指正文章中的错误。 基础入门 音视频开发入门：音频基础 音视频开发入门：视频基础 WebRTC音视频传输基础：NAT穿透 基础概念 WebRTC研究：MediaStream概念以及定义 Webrtc Glossary：查阅各种WebRTC相关概念 开始放弃。。。 编译 Windows平台WebRTC编译（持续更新） Windows平台WebRTC编译-VS2017 Linux平台WebRTC编译 WebRTC安卓编译 Mac平台WebRTC编译 网络参数 WebRTC研究：统计参数之丢包率 WebRTC研究：统计参数之抖动 WebRTC研究：统计参数之往返时延 WebRTC研究：码率计算 RTP/RTCP WebRTC研究：Transport-cc之RTP及RTCP（TransportFeedback） WebRTC研究：关键帧请求（PLI以及FIR） WebRTC研究：FEC之RED封装 WebRTC研究：RTP报头扩展 WebRTC研究：RTP时间戳的产生 WebRTC研究：Audio level WebRTC研究：H264 RTP包解析 WebRTC研究：H264 RTP包封装 WebRTC研究：RTP包组帧 QoS/QoE优化 WebRTC研究：RTP中的序列号以及时间戳比较 WebRTC研究：丢包判断 WebRTC研究：丢包重传机制-NACK WebRTC研究：视频FEC编码 WebRTC研究：视频FEC解码 WebRTC研究：NACK与FEC机制的配合 WebRTC研究：流畅模式与清晰模式 WebRTC研究：基于卡尔曼滤波的抖动估计 WebRTC研究：音频带内FEC WebRTC研究：基于Transport Feedback的早期丢包检测 浅谈基于SFU实现一对一效果 拥塞控制 WebRTC研究：包组时间差计算-InterArrival WebRTC研究：Trendline滤波器-TrendlineEstimator WebRTC研究：码率控制器-AimdRateControl WebRTC研究：应用受限区域探测器-AlrDetector WebRTC研究：DelayBasedBwe中绝对发送时间转换 WebRTC研究：带宽估计中的稳定估计值 WebRTC研究：Pacing机制 音视频引擎 WebRTC研究：Simulcast层数变化 WebRTC研究：Encoded Transform 基础库 WebRTC研究：线程模型 常见开源SFU源码分析 Licode研究：Pipeline架构 茶余饭后闲谈 WebRTC研究：WebRTC M89关键更新 WebRTC研究：记一次音频带宽估计引入的异常分析 小技巧 Chrome查看WebRTC日志 常用RFC RFC3550.RTP:A Transport Protocol for Real-Time Applications RFC2198.RTP Payload for Redundant Audio Data RFC5109.RTP Payload Format for Generic Forward Error Correction RFC5104.Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) RFC5285.A General Mechanism for RTP Header Extensions RFC8285.A General Mechanism for RTP Header Extensions RFC3984.RTP Payload Format for H.264 Video A Google Congestion Control Algorithm for Real-Time Communication draft-ietf-rmcat-gcc-02 RFC4585.Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) Transport CC.RTP Extensions for Transport-wide Congestion Control draft-holmer-rmcat-transport-wide-cc-extensions-01
JCH Hacker Typer:https://hackertyper.jianchihu.net/ Make your screen look like a real hacker command center in seconds. JCH Hacker Typer is built for normal users who want a cool, cinematic, and shareable experience — no technical knowledge needed. Why People Love It Instant “Hacker Movie” Atmosphere Press any key and watch realistic code flow across a dark terminal screen with a glowing cursor. Auto Typing Mode Turn on Auto Typing and the page keeps typing by itself — perfect for recording videos, livestream backgrounds, or event displays. Chat Simulation That Looks Real Includes a realistic chat window with: left/right message bubbles avatar dots and timestamps typing effect with blinking cursor your own input and Send button delayed auto-replies for a live conversation feel Dynamic Security Dashboard Feel Floating windows make the scene more convincing: security operation console system monitor with moving CPU, memory, and network charts Easy Visual Personalization Change colors, font size, backgrounds, and chat style to match your personal vibe or content theme. Better “Real Coding” Look Show line numbers and file navigation for a stronger developer-style impression. Feature Screenshots Main Hacker Interface Chat Simulation Window System Monitor Window Settings Panels Chat Settings Panels Best Use Cases Social media short videos Livestream visual effects Cyber-style personal homepage Film/TV background screens Event booth attract screens Ready to Promote If you want a website that looks modern, technical, and eye-catching, JCH Hacker Typer is a strong visual tool for audience attention. Use it to create a memorable first impression — and make your content instantly more engaging.
引言 随着短视频行业的蓬勃发展，视频编辑工具的需求日益增长。剪映国际版（CapCut）在国外占有很大市场。然而CapCut的恶心收费让那些老外感到恼火，这些老外骂起来也够狠。 至于怎么骂，可以看下这个链接：https://opencut.app/why-not-capcut，如下是部分截图： 因此，一个名为 OpenCut 的开源项目应运而生，旨在成为CapCut的免费替代品，为用户提供强大且无需联网的视频编辑体验。 OpenCut 是什么？ OpenCut作为一款免费、开源的视频编辑软件，致力于为用户提供媲美CapCut的视频编辑体验。支持Web、桌面端和移动端。OpenCut追求简单高效、隐私至上，所有视频内容都存储在本地，无需联网即可完成编辑，真正做到无水印、无订阅费用。 截至目前，该项目在 GitHub 上已获得超过8200个星标，还在快速上涨。 OpenCut 与 CapCut 的对比 特性 OpenCut CapCut 价格 完全免费，无订阅 部分功能需付费订阅 水印 无水印 免费版有水印 隐私 本地存储，无需联网 需联网，数据可能上传云端 跨平台支持 Web、移动端、桌面端支持 Web、移动端、桌面端支持 开源 是（MIT 许可证） 否 功能 多轨编辑、实时预览、特效等 功能丰富，但部分需付费解锁 从上表可以看出，OpenCut 在免费、无水印和隐私保护方面具有优势，适合预算有限以及注重隐私的用户。 核心功能 基于时间轴的多编辑 多轨道支持 实时预览 无水印且无需订阅 数据分析由Databuddy提供，100%匿名化且非侵入性 项目结构 apps/web/ – 主Next.js网站应用 src/components/ – UI和编辑器组件 src/hooks/ – 自定义React钩子 src/lib/ – 工具和API逻辑 src/stores/ – 状态管理（Zustand等） src/types/ – TypeScript类型 安装部署 参考：https://github.com/OpenCut-app/OpenCut 支持一键部署到免费的Vercel。 结语 之前以为老外有很好的付费习惯，没想到CapCut把国内恶心的收费毛病带到国外，惹毛老外。OpenCut目前实现还比较基础，不过开源社区的力量很强大，希望OpenCut后续能发展壮大，这个市场需要一点竞争。 参考 [1] https://github.com/OpenCut-app/OpenCut. [2] https://opencut.app/.
今天wordpress更新到6.8.1后页面顶部一直显示： Notice: 函数 _load_textdomain_just_in_time 的调用方法不正确。 kratos域的翻译加载触发过早。这通常表示插件或主题中的某些代码运行过早。翻译应在 init 操作或之后加载。 请查阅调试 WordPress来获取更多信息。 （这个消息是在 6.7.0 版本添加的。） in /usr/home/wh-axha23av59io7kixhgl/htdocs/wp-includes/functions.php on line 6121 参考这篇文章：https://xuv.cc/110/，删除主题文件style.css如下一行修复： [crayon-69ba7c2891a0c970636311/] 后面发现插件也有类似报错，懒得折腾，直接wp-config.php中关闭debug错误信息显示： [crayon-69ba7c2891a12782561133/]
前言 随着大模型语音对话时代的到来（ChatGPT-4o、Gemini Live、豆包等），高自然度、零/少样本语音克隆已经成为AI应用落地的核心痛点之一。无论是AI短剧配音、个性化数字人、语音客服、播客/有声书生产，还是本地化隐私部署，语音克隆TTS的质量、延迟、显存占用、跨语言能力都直接决定了用户体验。 本文是在2025年初测评、对比了十几款开源TTS方案后的记录。 TTS测评调研（基础工具篇） 在对比具体模型之前，先简单罗列一些常用的客观/主观评测手段，便于验证效果。 大模型语音对话时代的TTS评测实践 地址：QECon技术分享-大模型语音对话时代的TTS评测实践 微软评测服务 地址：使用发音评估 介绍了如何利用 Azure 语音服务的发音评估功能，通过编程实现对用户发音的自动评估。该功能可以分析语音的准确性、流畅性、完整性等指标，适用于语言学习、语音训练等场景。 seed-tts-eval（最常用客观指标） 地址：https://github.com/BytedanceSpeech/seed-tts-eval 用于最基础的评测，基本各个TTS模型论文里都会给出这两个指标，包括： 词错误率（WER）和语音相似度（SIM）指标。 对于词错误率，分别使用 Whisper-large-v3 和 Paraformer-zh 作为英语和中文的自动语音识别（ASR）引擎 对于语音相似度，使用在说话人验证任务上微调的 WavLM-large（模型链接）来获取说话人嵌入，用于计算每个测试语音样本与参考语音样本的余弦相似度 开源语音克隆TTS主流方案 F5-TTS 介绍 官方地址：https://github.com/SWivid/F5-TTS F5-TTS是由上海交通大学、剑桥大学与吉利汽车研究院联合研发的开源文本转语音（TTS）系统，其核心创新在于结合非自回归生成框架与流匹配（Flow Matching）技术，实现了高效且高质量的语音合成。项目基于扩散变换器（Diffusion Transformer, DiT）和ConvNeXt V2架构，通过流匹配优化生成路径，显著提升了语音的自然度和生成速度，推理效率较传统自回归模型提高数倍。 该系统的技术亮点包括： 非自回归并行生成：采用并行数据处理机制，突破传统逐帧生成限制，支持长文本（如30秒以上语音）的快速合成，同时降低显存占用 零样本声音克隆：无需目标语音数据训练，仅需15秒内的参考音频即可复刻说话人音色，支持多角色语音切换 多模态控制能力：集成情感表达调节与语速控制模块，可根据文本语义动态调整语音的情感强度和节奏 多语言与鲁棒性：在10万小时中英文混合数据集上训练，具备跨语言合成能力，并能有效处理复杂标点与特殊符号（如中文冒号自动转换） Demo 在线体验:https://huggingface.co/spaces/mrfakename/E2-F5-TTS CosyVoice 介绍 官方地址：https://github.com/FunAudioLLM/CosyVoice CosyVoice是由阿里巴巴通义实验室研发的开源语音合成大模型，专注于自然语言交互场景下的高保真语音生成。该项目基于监督离散语音标记技术，实现了多语言支持、音色克隆与情感控制的深度融合，其技术架构支持离线和流式一体化建模。 核心亮点包括： 仅需3秒音频样本即可完成音色克隆（基座模型CosyVoice-300M），支持中文、英文、日文、粤语等跨语种合成； 通过富文本或自然语言指令实现韵律、情感的细粒度控制（Instruct模型版本）； 在发音准确性和稳定性上较前代提升显著，MOS评分达5.53，接近商业化产品水平。 Demo 在线体验:https://huggingface.co/spaces/FunAudioLLM/CosyVoice2-0.5B Step-Audio-TTS-3B 介绍 官方地址：https://github.com/stepfun-ai/Step-Audio 阶跃星辰开源了一个130B 语音-文本多模态统一理解与生成模型：Step-Audio。Step-Audio通过其生成式语音数据引擎，能以更低的成本进行高质量的语音克隆。它通过“蒸馏”技术，将模型简化为一个更轻量的版本 Step-Audio-TTS-3B，并且这个模型也被开源，意味着任何人都可以使用和改进它。 Step-Audio 结合了语音理解与生成能力，提供了一种多模态的解决方案，能够有效支持多种语音交互场景。 该模型旨在解决现有开源语音模型在语音数据收集、动态控制和智能化方面的局限性。 这是一个集成语音识别、语义理解、对话生成、语音克隆、音频编辑和语音合成等功能的单一模型。该模型通过多模态训练，使得语音理解与生成可以无缝对接。 Step-Audio-Chat版本已经开源，支持高质量的对话生成。 Step-Audio通过其生成性语音数据引擎，消除了传统TTS（文本转语音）系统对人工语音数据收集的依赖。它能够生成高质量的语音数据，并通过其130B参数的模型训练出了资源高效的Step-Audio-TTS-3B模型，具备增强的指令跟随能力。 Demo 在线体验:https://www.modelscope.cn/studios/Swarmeta_AI/Step-Audio-TTS-3B ChatTTS-UI的语音克隆 介绍 官方地址：https://github.com/jianchang512/clone-voice 所用模型为coqui.ai出品的xtts_v ChatTTS-UI是一个集成语音克隆与视频翻译的端到端工具链，支持完全离线部署。clone-voice是其中一个声音克隆工具，可使用任何人类音色，将一段文字合成为使用该音色说话的声音，或者将一个声音使用该音色转换为另一个声音。 Demo Demo下载地址：https://pyvideotrans.com/ fish-speech 介绍 官方地址：https://github.com/fishaudio/fish-speech Fish Speech 是一个全新的文本转语音(TTS)解决方案，该项目由fishaudio开发。 当前模型使用约十五万小时三语数据训练，对中文支持非常的完美。 能够熟练处理和生成中文、日语和英语的语音，语言处理能力接近人类水平，并且声音表现形式丰富多变。 DualAR 架构：双自回归Transformer设计。主 Transformer 以 21Hz 运行，次Transformer将潜在状态转换为声学特征。计算效率和输出质量都优于传统的级联方法。 训练数据：拥有 100 万小时的多语言训练数据； 高准确率：英文单词错误率（WER）为3.5%，英文字符错误率（CER）为1.2%，中文字符错误率（CER）为1.3%； 低延迟：语音克隆延迟低于 150 毫秒。 强泛化：摒弃了传统的音素依赖，直接理解与处理文本，无需繁杂的语音规则库。 Demo 在线体验:https://fish.audio/train/new-model/ OpenVoice 介绍 OpenVoice 是由MyShell AI推出的一个免费开源的AI即时语音克隆项目，仅需短语音片段即可复制参考说话者的音色，同时支持情感、口音、韵律等多维风格控制。该项目实现了零样本跨语言语音克隆，无需针对每种语言收集大规模说话者数据。 技术亮点： 细粒度风格控制（情绪、语速、停顿等） 零样本跨语言克隆，极大降低数据需求 计算效率高，适用于大规模部署 Demo 在线体验：https://huggingface.co/spaces/myshell-ai/OpenVoice Spark-TTS 介绍 Spark-TTS是一种新型的文本转语音（TTS）系统，它的核心是BiCodec——一种单流语音编解码器。这个编解码器可以把语音分解成两种互补的“语音令牌”:一种是低比特率的语义令牌，用来捕捉语言内容;另一种是固定长度的全局令牌，用来捕捉说话者的属性，比如音色、音调等。这种分离式的表示方法，结合了强大的Qwen2.5语言模型和一种叫做“思维链”(CoT)的生成方法，让Spark-TTS能够实现从粗粒度(比如性别、说话风格)到细粒度(比如精确的音高值、说话速度)的控制。 Sesame语音模型CSM（没有AI味） 介绍 在语音合成技术的发展中，有一个长期存在的挑战——“恐怖谷效应”（Uncanny Valley）。 当人工合成的语音接近真实人声但仍然存在微小差异时，人类会感到奇怪或不适，这就是所谓的“恐怖谷效应”。 Sesame 公司的目标是研发一种语音模型，跨越这一“恐怖谷”，让用户感到与AI的语音交互如同与真人对话般自然。他们提出了“语音存在感”的概念，指语音交互中让人感到真实、被理解和被重视的特质。他们希望通过技术创新，让AI语音不仅听起来像人，还能在情感和语境上与用户产生共鸣。 实现“语音存在感”的三大核心要素： 情商（Emotional Intelligence）：模型需能感知并回应用户的语气、情绪和对话背景。例如，当用户表现出开心或沮丧时，AI能相应调整语调和内容。 低延迟（Low Latency）：为了让对话流畅自然，AI的响应时间必须极短，接近人类对话中的即时反应。 语音质量（Voice Quality）：声音需逼真且富有表现力，避免机械感，同时保留细腻的语调变化。 为了实现这些目标，Sesame开发了对话语音模型（Conversational Speech Model，简称CSM）。该模型采用端到端的多模态学习方法，利用Transformer架构，结合对话历史生成更自然、连贯的语音输出。与传统的文本转语音（TTS）模型不同，CSM不仅关注高质量的音频生成，更强调对上下文的实时理解和适应，从而解决了传统模型在多样性和情境适应性方面的不足。 Sesame公司展示了他们最新的研究成果，他们使用了约100万小时的公开音频数据进行训练了一个语音模型，它在个性、记忆、表达能力和恰当性上表现出了非常惊人的能力。 Sesame演示（Demo）的语音合成质量已经超越OpenAI的高级语音模式（Advanced Voice Mode）。 目前只支持英文，听说后面会开源模型。 Demo 在线体验:https://www.sesame.com/research/crossing_the_uncanny_valley_of_voice#demo GPT-SoVITS（中文/粤语少样本克隆黑马） 介绍 GPT-SoVITS是一款强大的少样本语音转换与语音合成工具。 官方地址：https://github.com/RVC-Boss/GPT-SoVITS 极低门槛克隆：零样本只需5秒参考音频即可合成（相似度80%+），1分钟few-shot微调后相似度可达95%+，甚至接近商业级 支持中、日、英、韩、粤五语种，且跨语言合成能力强（粤语表现尤为出色，常被称“粤语天花板”） WebUI极其友好，一键训练+推理，Windows集成包直接双击运行 v3/v4大幅提升zero-shot相似度、情绪表现力和微调效果；v4修复电音问题，原生48k输出更通透不闷 推理速度快（RTX 4090 RTF≈0.014，4060Ti也能实时），显存占用适中（v2Pro/v4 ≈ v3的性能但更省资源） 社区生态活跃，常与RVC、ComfyUI插件结合，用于配音、唱歌、实时变声等场景 Demo Hugging Face官方/社区Demo（高速推理）：https://huggingface.co/spaces/lj1995/GPT-SoVITS-ProPlus （或搜索“GPT-SoVITS”找最新fork） 总结 前面方案中，经测试，支持最全，方便后续微调，效果最好的要数GPT-SoVITS方案了。
Conda 环境 [crayon-69ba7c289355a031170365/] Ollama配置 [crayon-69ba7c2893560851389731/] 通过Ollama下载需要的大语言模型以及嵌入模型，这里用的阿里千问以及nomic。 [crayon-69ba7c2893561416831912/] 代码下载以及依赖安装 [crayon-69ba7c2893562894790826/] 环境配置 创建一个目录用于存放输入的文本数据集，例如txt，csv文档。 [crayon-69ba7c2893564571356804/] 初始化./ragtest目录用于生成默认环境配置文件。 [crayon-69ba7c2893565314581617/] ./ragtest目录下settings.yaml为默认配置文件，配的是Chatgpt模型，由于我们通过Ollama使用本地大模型，所以需要修改配置，可以使用如下内容直接替换settings.yaml中的配置： [crayon-69ba7c2893566581456858/] 修改内容如下： [crayon-69ba7c2893567592425181/] 配置文件参数说明参考：https://microsoft.github.io/graphrag/posts/config/json_yaml/ 提示词微调 在当前工作目录ragtest下，用于大模型提取实体以及关系等的提示词默认存放在prompts子目录下，可通过settings.yaml修改提示词目录。对于特定领域，默认提示词模板表现不佳。这里我们可以通过官方提供的方法进行提示词微调，替换默认提示词模板，从而提高在特定领域上的表现。 自动模板 可以通过配置domain，language等参数，生成符合我们要求的提示词模板，如下是针对某电影拍摄书籍的一个自动模板提示词微调示例。这样就会在prompt目录下生成新的提示词模板，更符合拍摄领域。 [crayon-69ba7c2893569170336559/] 详细参数配置可以参考：https://microsoft.github.io/graphrag/posts/prompt_tuning/auto_prompt_tuning/ 手动提示词微调 按照规范自己写一个提示词模板，参考：https://microsoft.github.io/graphrag/posts/prompt_tuning/manual_prompt_tuning/ 执行索引 这一步会通过大模型提取实体，关系等，构建知识图谱，耗时较久。 [crayon-69ba7c289356a302867898/] 搜索 索引阶段提取的结构被用来提供材料，作为LLM的context来回答问题。查询模式包括本地和全局的搜索： 本地搜索：通过图谱中实体关联信息和原始文档相关文本块来推理关于特定实体的问题 全局搜索：通过社区的总结来推理关于语料库整体问题的答案 本地搜索 [crayon-69ba7c289356b974662945/] 全局搜索 [crayon-69ba7c289356c051915096/] 参考 [1] https://microsoft.github.io/graphrag/posts/query/overview/
基于SFU架构的视频会议系统中，Simulcast是最主流的带宽自适应方案。发布端（Publisher）同时编码并发送多路不同分辨率的流（通常为小、中、大三路），订阅端（Subscriber）则根据自身网络带宽、设备性能、窗口大小等因素，选择订阅最合适的单路流。这种设计发布端与订阅端互不干扰： 发布端仅受自身上行带宽和编码负载影响 订阅端仅受自身下行带宽，解码能力，显示窗口影响 但在实际生产环境中，某些核心场景却需要订阅端能够“反向影响”发布端，即实现backpressure（反压）机制。 反压需求场景 按需推流 当会议中所有订阅端都处于小窗口显示（如宫格数较多、缩略图模式）时，大家只会订阅小流。此时发布端若仍持续推送大流，就会造成巨大的上行带宽浪费和服务器转发压力。理想状态是：订阅端集体选择小流 → SFU 通知发布端自动降档，只推小流即可。 SFU模拟点对点（P2P）通话 用SFU统一实现1对1通话（便于后续扩展多人）。此时必须达到原生P2P（ICE直连）的体验。 订阅端网络恶化时，不能仅靠切换Simulcast层（因为只有一层流），而应直接让发布端降低编码码率/分辨率 订阅端网络恢复后，发布端也要快速回升 在传统Simulcast中做不到这样的“端到端拥塞控制”。 SFU如何实现订阅端反压 核心思路：在SFU内部为每个发布源（Source）和每个订阅接收器（Sink） 建立反馈通道，让订阅客户端的带宽估计结果能够传递到发布客户端。 下面是实现原理图： 发布客户端 → RTP → SFU Source（发布源） SFU Sink（订阅接收器）收到订阅端发来的 Transport-CC报文，进行下行带宽估计 Sink通过onFeedback接口将估计带宽值传递给对应的Source Source封装REMB（Receiver Estimated Maximum Bitrate）RTCP报文，传回到发布客户端 发布客户端收到REMB后，强制限制自身带宽估计值 这样就实现了订阅端 → SFU → 发布端的完整反压闭环。 REMB RTCP报文复用 WebRTC早期就内置了REMB RTCP，用在最早的接收端带宽估计中，接收端的带宽估计就是通过REMB反馈到发布端。虽然现在是Transport-CC + Sendside BWE，但REMB仍然被支持。这里可以看下REMB报文格式： [crayon-69ba7c28940b7974326384/] 对于SFU，带宽反馈处理只需在 Source 侧调用： [crayon-69ba7c28940bc988599270/] 发布客户端中WebRTC收到REMB后的处理如下： [crayon-69ba7c28940be505067959/] 至此我们完成初步的反压实现。 遗留问题：弱网解除后带宽恢复速度慢 前面实现后还有个问题，就是订阅端弱网恢复后，恢复之前码率较慢。原因如下： 订阅端之前带宽差 → SFU反馈低REMB → 发布端码率被压得很低 订阅端网络恢复 → 其BWE想提升，但实际收到的码率仍然很低（受发布端限制） 订阅端BWE探测不到更高带宽 → 继续反馈低REMB → 发布端无法提升 → 形成“死循环” 这就像“受制于人”，恢复速度远慢于原生的P2P实现。 这时候我们可以在SFU的Sink（下行）侧中，主动注入探测流量，也就是引入探测（Padding）包。让订阅端能够获得额外码率进行更大带宽探测，打破死循环，加快恢复到之前码率。 总结 通过以上机制，SFU不仅保留了Simulcast的灵活性，还具备了端到端拥塞控制能力，让视频会议在复杂网络环境下也能提供接近原生P2P的流畅体验。
目前H265应用越来越广泛，很多设备都支持硬件加速的H265编解码。作为最常见的音视频终端，Chrome在过去一直都没有H265支持的，毕竟不是AV1那样的亲儿子。人们为了让Chrome完整支持H265，用上了各种招式，例如传输上，用到了datachannel/WebTransport传输H265码流，解码上用到了wasm。 在Native端，要支持H265，得自己魔改WebRTC代码，例如第三方开源WebRTC库：Intel的OWT。现在这些状况就要改变了，目前Chrome已经支持H265硬解，WebRTC上也开始进行H265支持的开发，这一切都要从这个讨论开始： Issue 41480904:Unblock Chrome platform support of H.265 (including H26xPacketBuffer)，提到目前很多安防摄像机都是默认H265编码，修改为H264代价太高，大概率是国人提的需求😀。 目前WebRTC中H265代码由Intel团队的人提交，跟Intel自己的开源WebRTC库OWT中代码相似。目前代码中（截至2023.9.20）中主要三个提交，增加了H265 Nalu的解析，SDP中相关定义，RTP包处理/编解码器相关预留H265坑位，离实际能使用还有很多事情要做，如果感兴趣，也可以先看下Intel OWT中的H265代码，代码中搜索OWT_ENABLE_H265字段，就可以看到H265相关。本文后续也将继续跟踪H265进展。 2025-03-12代码更新 Revert the deletion of WebRTC-VideoH26xPacketBuffer flag [crayon-69ba7c2894c23747826043/] 如上提交后，之前提到的Issue 41480904也被标记为fixed了，从2021到2025四年的跨度，WebRTC总算完成H265的支持。 根据提交代码可以知道，WebRTC-VideoH26xPacketBuffer特性默认关闭的，接收到视频RTP包时，相关处理如下： [crayon-69ba7c2894c28923095099/]
