webrtc (6) 在Webrtc中集成VideoToolbox

最新推荐文章于 2022-10-09 17:46:01 发布
最新推荐文章于 2022-10-09 17:46:01 发布
阅读量6.5k 收藏 1
点赞数 1
分类专栏： webrtc iOS VideoToolbox video 文章标签： VideoToolbox H264 硬件编码 Hardware H.264 iOS
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wangruihit/article/details/46550853
版权
本文介绍了如何在iOS平台利用VideoToolbox Framework集成硬件H264编解码功能，涉及I420与NV12格式转换、AVCC到Annex-B的数据格式转换、关键帧检测、PTS处理以及使用PixelBufferPool提升性能。参考了WWDC视频、OpenWebRTC代码和StackOverflow帖子，适合iOS开发者了解硬件编码技术。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

VideoToolbox是iOS平台在iOS8之后开放的一个Framework，提供了在iOS平台利用硬件实现H264编解码的能力。


这套接口的合成主要我一个人参与，花费了四五天的时间，中间主要参考了WWDC 2014  513关于hardware codec的视频教程，

OpenWebrtc的vtenc/vtdec模块，

chromium的一部分代码

https://src.chromium.org/svn/trunk/src/content/common/gpu/media/vt_video_decode_accelerator.cc，

https://chromium.googlesource.com/chromium/src/media/+/cea1808de66191f7f1eb48b5579e602c0c781146/cast/sender/h264_vt_encoder.cc

还有stackoverflow的一些帖子，如 

http://stackoverflow.com/questions/29525000/how-to-use-videotoolbox-to-decompress-h-264-video-stream 

http://stackoverflow.com/questions/24884827/possible-locations-for-sequence-picture-parameter-sets-for-h-264-stream

另外还有apple forum的帖子如：

https://devforums.apple.com/message/1063536#1063536


中间需要注意的是，

1，YUV数据格式

Webrtc传递给Encoder的是数据是I420，对应VT里的kCVPixelFormatType_420YpCbCr8Planar，如果VT使用

kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange格式（即NV12），那么需要将I420转换为NV12再进行编码。转换可使用libyuv库。

I420格式有3个Planar，分别存放YUV数据࿰

最低0.47元/天 解锁文章
WebRTC[35]-WebRTC之MediaCodec
liuzhen007的专栏
09-20 544
目录 前言 正文 C层和Java层的方法映射关系 处理 SDP 信息 准备视频编码参数 开始视频编码 结尾 PS:《WebRTC工作原理精讲》系列-总览 前言 WebRTC为了实现在 Android 端的硬编硬解功能，引入了 MediaCodec 模块。对比 iOS 端的VideoToolbox 和 AudioToolsbox，今天，我们先了解一下 Android 端的硬编硬解模块MediaCodec。 正文 WebRTC 最新的版本默认都是硬编软解，为了保证兼容性，限制了...
Webrtc支持FFMPEG硬解码之解码实现（三）
qq_15821883的博客
06-13 720
Webrtc支持FFMPEG硬解码之Intel（一）-CSDN博客Webrtc支持FFMPEG硬解码之NVIDA（二）-CSDN博客Webrtc支持FFMPEG硬解码之解码实现AMD硬解目前还没找到可用解码器，欢迎留言交流以对于编码器，FFMMPEG里面搜索编码器的名称，即可找到，例如“h264_qsv”encoder, 参见：qsvenc_h264.c对于解码器，FFMPEG采用了宏定义方式实现，例如：“h264_qsv” decoder，参见qsvdec.c文件​。
WebRTC视频数据流程分析
LiveVideoStack
09-10 1443
本文来自《WebRTC Native开发实战》书籍作者许建林在LiveVideoStack线上分享中的内容，详细分析总结 WebRTC 的视频数据流程，并对大型项目如何快速上手：分析方法...
WebRTC音视频通话（三）整合websocket
m0_60259116的博客
10-09 1295
WebRTC音视频通话（三）整合websocket
RTC toolbox学习记录
qq_32209209的博客
04-07 589
f = rtccurve([[0 2 2]], [[0 0 1];[2 2 0.25]], 3, 10, 5, 4); rtcplot(f, 20); 两部分曲线，一部分为非周期曲线，从（0，0）开始，斜率为1； 另一部分曲线为周期曲线，周期为5，offset=4，从（3，10）开始。 offset：可以明确指出周期性部分的两个连续重复之间的Y轴偏移。 ...
基于iOS的网络音视频实时传输系统(H264+pcm+videoToolbox)无第三方实现
04-11
基于iOS的网络音视频实时传输系统(H264+pcm+videoToolbox)无第三方实现 tcp 局域网 编解码 音视频 https://blog.csdn.net/github_35041937/article/details/89192781
深入浅出 WebRTC AEC（声学回声消除）
我的博客
08-21 7671
回声的形成 WebRTC 架构中上下行音频信号处理流程如图 1，音频 3A 主要集中在上行的发送端对发送信号依次进行回声消除、降噪以及音量均衡（这里只讨论 AEC 的处理流程，如果是 AECM 的处理流程 ANS 会前置），AGC 会作为压限器作用在接收端对即将播放的音频信号进行限幅。 那么回声是怎么形成的呢？ 如图 2 所示，A、B 两人在通信的过程中，我们有如下定义： x(n): 远端参考信号，即 A 端订阅的 B 端音频流，通常作为参考信号； y(n): 回声信号，即扬声器播放信号 x(n) 后，被
WebRTC系列-H.264预估码率计算
HOSTEN的博客
07-05 850
WebRTC源码中对视频的编码数据最终处理都是I420数据，由此可知一帧未编码的数据的大小是： width x height x 1.5 这里的单位是字节，例如：6404801.5 = 460,800Byte ; (VBR下)一般的压缩比一般能达到1：50甚至1：100以上，按照640 480 @ 15fps的计算：一般的影响评估码率的因素主要有以下几种：根据不同的典型应用业务场景，常见的码率限制要求(码率控制的模式)，大致总结为以下几种类型: 使用的VideoToolBox框架只支持ABR模式。设置
webRTC中回声消除（AEC）模块的编译与测试
李江龙的博客
06-08 5920
整体过程同webRTC降噪（NS）、自动增益控制（AGC）模块的编译与测试一样，只是在aec_rdft.c文件中可能会报错，局部变量ip跟全局变量冲突的问题，可以将局部变量重新命名一下，就可以通过编译了。修改后的代码如下/* * http://www.kurims.kyoto-u.ac.jp/~ooura/fft.html * Copyright Takuya OOURA, 1996-2001...
webrtc 的回声抵消(aec、aecm)算法简介
热门推荐
u012931018的专栏
11-30 1万+
webrtc 的回声抵消(aec、aecm)算法简介      webrtc 的回声抵消(aec、aecm)算法主要包括以下几个重要模块：1.回声时延估计 2.NLMS(归一化最小均方自适应算法) 3.NLP（非线性滤波） 4.CNG(舒适噪声产生），一般经典aec算法还应包括双端检测(DT)。考虑到webrtc使用的NLMS、NLP和CNG都属于经典算法范畴，故只做简略介绍，本文重点介绍web
【转】WebRTC AECM时延估计
hdm314的博客
09-01 1450
时延问题：一般基于互相关计算的自适应时延估计算法的计算复杂度为，其随计算范围的增长呈二次上升趋势，因此很难再如此大的范围内进行动态地时延计算。在实际应用中一般采用大范围粗略估计加小范围精确计算的方法，例如在WebRTC的AECM回声消除模块中，其API接口中有一个特殊的参数msInSoundCardBuf，要求调用者传入一个以毫秒为单位的回声时延估计值，然后又AECM内部在这个估计值的基础上进行**小范围内回声时延精确计算，因此该参数的准确性将直接音响到AECM内部时延计算准确性和速度，而这种影响又能直观的
WebRTC android h264 编解码适配（三）
m370809968的专栏
08-23 2446
最近升级webrtc（m72版本），发现webrtc源码发生了不小的变动，尤其是在视频编解码这块，之前的MediaCodecVideoEncoder,MediaCodecVideoDecoder已经不再使用了，改成HardwareVideoDecoderFactory,HardwareVideoEncoderFactory了，创建编解码器也交给了上层去创建了，下面是创建编解码器的代码： ...
Webrtc创建Android端编码器流程
cffishappy的专栏
02-26 2113
1.根据info创建对应的硬软编码器（vp8还是H264），优先选择硬编码 public VideoEncoder createEncoder(VideoCodecInfo info) { final VideoEncoder softwareEncoder = softwareVideoEncoderFactory.createEncoder(info); final VideoEncoder hardwareEncoder = hardwareVideoEncoderFactory.cr
如何开启浏览器硬件加速
waiter89的专栏
04-19 5459
浏览器开启视频加速
关于IOS VideoToolBox的一些汇总
dongtinghong的专栏
03-03 1万+
1. 至少从iPhone4开始，苹果就是支持硬件解码了，但是硬解码API一直是私有API，不开放给开发者使用，只有越狱才能使用，正常的App如果想提交到AppStore是不允许使用私有API的。 2. 从iOS8开始，可能是苹果想通了，开放了硬解码和硬编码API，就是名为 VideoToolbox.framework的API，需要用iOS 8以后才能使用，iOS 7.x上还不行。
iOS 音视频采集与编码
Keep_Moving31038的博客
08-29 2347
学习过音视频的都知道，不常用的话就会容易忘记。因此，记下以前学些的点滴。（这不是入门贴） 主要分为以下主题做学习记录： 视频采集与编码音频采集与编码 video.png 视频采集与编码 视频采集 获取输入设备 NSError *deviceError; AVCaptureDeviceInput *inputDevice; for (AVCaptureD
调用webrtc里面提供的方法获取视频数据并存储YUV文件
CHNIM的博客
07-31 1813
#include "webrtc/base/refcount.h" #include "webrtc/base/scoped_ref_ptr.h" #include "webrtc/modules/video_capture/windows/video_capture_ds.h" #include "webrtc/modules/video_capture/video_capture_facto...
WebRTC56版本SDP详细解析
chinabinlang的专栏
01-24 1万+
http://blog.csdn.net/onlycoder_net/article/details/76702432 v=0 //sdp版本号，一直为0,rfc4566规定 o=- 7017624586836067756 2 IN IP4 127.0.0.1 // RFC 4566 o=<username> <sess-id> <sess-versio...
webrtc中的h264解析
chinabinlang的专栏
09-28 1858
H264的码流解析，网上有很多开源文件；一般的解析有： 获取NALU，sps，pps，NALU type，slice type，获取Qp等；可以通过C++的位运算实现获取计算，但是一般可以定义结构体直接获取；这里要说的是webrtc中的H264解析相关：在webrtc中，关于H264的相关源码文件在：webrtc58\src\webrtc\common_video\h264中；都包含了很好的函数：...
webrtc-streamer延迟大
最新发布
03-27
<think>好的，我需要帮助用户解决WebRTC-Streamer延迟大的问题。首先，我得先理解用户的需求。他们提到延迟高，特别是在TV上，但又不卡顿。这可能和网络传输、编码设置或者硬件性能有关。 根据引用[4]，里面提到parking_lot这个Rust库的mutex实现比标准库好，可能影响性能，但不确定是否直接相关。不过，里面还提到选择Rust实现实时通信技术，可能涉及到底层优化。不过用户的问题是关于WebRTC-Streamer的具体配置优化，所以可能需要更多关于WebRTC本身的优化策略。 首先，我应该考虑常见的WebRTC延迟优化方法，比如调整编码参数，使用低延迟配置，优化网络传输等。比如，使用H.264/VP9的low-latency模式，调整关键帧间隔。然后，检查网络状况，确保带宽足够，使用适当的拥塞控制算法，比如Google的BBR。另外，服务端和客户端的配置也很重要，比如开启硬件加速，减少缓冲等。 然后，用户提到最佳实践和配置优化，可能需要具体参数调整，比如在WebRTC-Streamer中设置--h264-profile=baseline或者使用--video-bitrate来限制码率。另外，使用UDP而不是TCP，减少重传带来的延迟。还有调整ICE服务器的设置，优化NAT穿透。 还要考虑硬件方面的优化，比如使用更好的GPU进行编码，或者调整系统资源，确保没有其他进程占用过多CPU/内存。另外，检查时间戳同步，确保音视频同步，避免因为同步问题导致的延迟。 可能需要分步骤来回答，先分析可能的原因，再给出具体的优化措施，每个措施要有依据，比如引用相关文档或最佳实践。如果有引用到站内的资料，比如引用[4]中提到的parking_lot，虽然主要讲的是Rust的同步原语，但可以提到系统级资源竞争可能影响延迟，确保代码中的锁机制高效，但这点可能属于更底层的优化，用户可能无法直接修改WebRTC-Streamer的代码，所以可能更侧重配置调整。 另外，用户提供的引用[1]提到Stadia TV上手柄输入延迟高，可能和渲染或解码有关，可以建议检查客户端解码器的性能，或者使用低延迟的解码器设置。 总结下来，回答的结构应该是先分析可能的原因，再分点列出优化方法，每个方法具体说明如何操作，可能涉及配置参数、网络调整、硬件加速等。最后生成相关问题，引导用户进一步解决可能出现的问题。</think>### 如何降低 WebRTC-Streamer 的延迟 #### 1. **调整编码参数** - **使用低延迟编码模式**：在启动`webrtc-streamer`时，指定编码参数为低延迟模式，例如设置H.264的`baseline`或`constrained baseline`档次，减少编码复杂度： ```bash webrtc-streamer --video-codec=H264 --h264-profile=baseline ``` - **降低关键帧间隔**：缩短关键帧（I帧）间隔，减少因帧间依赖导致的延迟。例如设置`--keyframe-interval=20`（单位：帧）[^4]。 - **限制码率与分辨率**：根据网络带宽动态调整码率，避免拥塞。例如使用`--video-bitrate=2000`（单位：kbps）和`--video-size=1280x720`。 #### 2. **优化网络传输** - **启用UDP协议**：WebRTC默认使用UDP，确保未因防火墙限制回退到TCP。可通过日志检查传输协议。 - **调整ICE与NAT穿透**：配置高效的STUN/TURN服务器，减少连接建立时间。例如使用`--stun-url=stun:stun.l.google.com:19302`。 - **拥塞控制算法**：在服务端启用Google BBR等高效算法，优化带宽利用率[^4]。 #### 3. **硬件加速与系统优化** - **启用硬件编码**：若设备支持，使用GPU加速编码（如NVIDIA NVENC）： ```bash webrtc-streamer --hw-accel=cuda ``` - **减少缓冲区**：调整音视频缓冲大小，例如设置`--audio-buffer-size=50`（单位：ms）和`--video-buffer-size=100`。 - **系统资源隔离**：避免其他进程占用CPU/GPU资源，可通过`cgroups`或优先级调整优化资源分配。 #### 4. **客户端解码优化** - **低延迟解码器**：确保客户端使用硬件解码（如Android的MediaCodec或iOS的VideoToolbox）。 - **禁用非必要处理**：关闭客户端后处理效果（如美颜、降噪），减少解码后处理时间[^1]。 #### 5. **监控与调试** - **日志分析**：通过`webrtc-streamer`的详细日志（`--verbose`）检查各环节耗时。 - **网络诊断**：使用`tcping`和`traceroute`排查网络抖动与路由问题。 ---
评论 5
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值