尧图网站建设 
目录 前言直播技术框图 1. AI 眼镜数据源概述1.1 硬件分工与音视频采集1.2 跨芯片传输与无线输出链路2. AI 眼镜直播流程概述3. Wi-Fi P2P 连接方案讨论3.1 相关概念3.2 P2P/IP/TCP/Socket3.3 三种 P2P 连接方案3.3.1 方案一 Phone Auto Connect3.3.2 方案二 Phone Manual Connect3.3.3 方案三 Phone GO3.3.4 方案异同点3.3.5 WifiP2pConfig 讨论1P2pFrequencyHelper2setGroupOperatingBand 与 setGroupOperatingFrequency4. ⚛️ 手机实时预览实现4.1 视频预览4.2 音频播放5. ✅ 手机推流概述5.1 腾讯直播 SDK 初始化与参数配置5.2 视频推送5.3 音频推送5.4 房间管理、心跳与弹幕交互 小结 前言随着可穿戴设备与人工智能技术的深度融合基于 RTOS实时操作系统的轻量化 AI 眼镜正逐渐成为第一视角POV实时直播与交互的重要终端RTOS 平台具备极致的低功耗、快速启动和高实时性优势但受限于硬件资源与功耗预算其在音视频编码、复杂网络协议栈处理及长距离无线传输方面面临天然挑战为突破上述瓶颈本技术方案设计并实现了一套“AI 眼镜采集 — 手机中枢处理 — 云端分发互动”的三端协同直播架构AI 眼镜端AI Glass采用低功耗双芯片物理隔离架构STM32N6 主控挂载 Camera 完成画面采集与 H.264/MJPEG 硬件压缩物奇 WuQi 芯片处理麦克风阵列数据及 3A 降噪算法输出 Opus 音频流通过板载 I2S/UART 高速总线进行跨芯片数据汇聚手机端Phone作为中转与控制中枢基于“蓝牙信令控制 Wi-Fi P2P 高带宽传输”的双通道握手机制建链利用“生产者-消费者”异步线程队列与 MediaCodec 硬解码实现本地零拷贝低延迟预览同时集成腾讯云直播 SDKV2TXLivePusher进行横屏码率自适应推流云端Cloud基于直播云平台如腾讯云完成音视频流的转码、存储与 CDN 全网分发结合 IM 互动系统将弹幕消息实时反向回传至眼镜端形成完整的闭环体验。直播技术框图下图为系统的整体技术架构框图概述了各模块间的分工、协议传输与数据流向。 1. AI 眼镜数据源概述本方案基于RTOS AI 眼镜的双芯片硬件架构在进行手机端直播与推流前眼镜端负责完成音视频的原生采集、前级处理以及跨芯片的同步传输等。1.1 硬件分工与音视频采集眼镜端采用低功耗双芯片架构音频与视频采集物理隔离视频源STM32N6 主控 负责挂载 Camera 模块采集画面并进行硬件压缩输出H264 / MJPEG视频帧。音频源物奇 WuQi 芯片 负责麦克风阵列的数据捕获经底层 3A 算法降噪、回声消除处理后输出Opus音频流。1.2 跨芯片传输与无线输出链路由于音视频挂载在不同芯片上系统根据不同的无线连接场景在眼镜内部通过高速物理总线I2S / UART进行一级数据汇聚最终通过 Wi-Fi 或蓝牙BT将数据流交付给手机端无线模式眼镜端内部流向与无线输出Wi-Fi 模式视频STM32N6 → Wi-Fi → 手机端音频物奇 (Audio) → I2S 总线 → STM32N6 → Wi-Fi → 手机端BT 蓝牙模式视频STM32N6 (Video) → UART 串口 → 物奇 → 蓝牙 → 手机端音频物奇 (Audio) → 蓝牙 → 手机端注本文主要阐述 Wi-Fi 模式BT 模式就不在此赘述。2. AI 眼镜直播流程概述本方案采用 “蓝牙信令控制 Wi-Fi P2P 高带宽传输” 的双通道架构同时手机端通过蓝牙动态获取眼镜端的 Socket 接口IP/Port实现了无缝的 P2P 直连建链。初始化Bluetooth 交互指令触发用户在眼镜端发起直播眼镜通过蓝牙通道向手机发送开启直播控制指令任务初始化手机蓝牙模块接收指令并创建直播本地任务同时通过蓝牙指令唤醒眼镜 Wi-Fi并拉取眼镜 Wi-Fi 的 MAC、IP、Port 信息。网络建立与数据传输通道建链Wi-Fi P2P / Socket网络建立手机蓝牙模块向 Wi-Fi 模块发起连接网络连接数据传输通道建链Wi-Fi 模块完成 P2P 点对点握手 与 Socket 数据通道建链同时通过蓝牙模块通知眼镜直播开启成功。音视频推流与处理Wi-Fi 高速通道推流眼镜通过 Wi-Fi 通道开始高速推送音视频流分发与渲染手机网络层接收流数据并分发至 App 业务层进行解码、播放以及转推至 CDN。3. Wi-Fi P2P 连接方案讨论3.1 相关概念概念定义在 AI 眼镜 P2P 场景中的作用P2P(Peer-to-Peer)点对点通信方式设备之间直接建立连接进行数据交换实现手机与 AI 眼镜直接通信用于传输音视频和控制数据Wi-Fi P2P(Wi-Fi Direct)基于 Wi-Fi 的设备直连技术无需依赖路由器提供手机与眼镜之间高速、低延迟的数据传输链路GO(Group Owner)Wi-Fi P2P 网络中的管理设备类似 Wi-Fi 热点角色创建 P2P 网络并管理 Client 设备接入GC(Group Client)加入 Wi-Fi P2P 网络的设备连接 GO获取网络信息后与对端进行通信SSIDWi-Fi 网络名称用于标识无线网络标识 P2P 网络例如 DIRECT-P2P-A1B2用于设备发现和连接MAC 地址网络设备的硬件唯一标识蓝牙发现设备时使用并用于生成 P2P SSID例如 DIRECT-P2P-A1B2Band(频段)表示 Wi-Fi 工作在哪个频段决定在哪个频率范围工作例如 5GHz 或 2.4GHzChannel(信道)表示频段下面的多个信道决定该频段中的具体信道例如 5GHz Channel 153 或 2.4GHz Channel 6goIntent(Group Owner Intent)希望自己成为 GO 的意愿值取值范围 0~15数值越大越希望自己成为 GO默认值 2 是倾向做ClientIP 地址网络中设备的唯一地址用于设备定位Wi-Fi P2P 建立后通过 IP 地址找到手机或眼镜设备Port(端口)用于区分设备上的不同网络服务区分视频、音频、控制等不同 Socket 服务TCP可靠传输协议保证数据完整和顺序用于传输控制指令、配置数据等可靠性要求高的数据UDP面向实时传输的协议延迟较低用于传输实时音视频数据降低直播延迟Socket应用程序进行网络通信的接口手机 App 与眼镜通过 Socket 建立连接实现数据收发3.2 P2P/IP/TCP/Socket咱们一起回顾下P2P、IP、TCP、Socket等关键技术在 OSI 七层模型的联系。在OSI模型中物理层和链路层的“Wi-Fi P2P”打通设备直连网络层的“IP”负责寻址定位传输层的“TCP”确保数据可靠送达而会话层的“Socket”则作为它们与应用层之间的通信接口共同支撑了上层音视频和控制数据的稳定传输。3.3 三种 P2P 连接方案本节的核心内容是对第 2 节 AI 眼镜直播流程图Wi-Fi Connect部分的细化基于手机 App 与 AI 眼镜之间通过 Wi-Fi P2P 进行直连目前调研并完成联调实现了三种连接方案眼镜作为 GO手机自动连接眼镜Phone Auto Connect眼镜作为 GO手机手动连接Phone Manual Connect手机作为 GO眼镜手动连接Phone GO3.3.1 方案一 Phone Auto Connect第 2 节 AI 眼镜直播流程图采用的方案一手机 App 自动发现眼镜并主动建立 Wi-Fi P2P 连接连接成功后通过 Socket 进行音视频数据传输。清理与重置环境调用 WifiP2pManager.removeGroup 移除已有的历史组网内部延迟300ms确保旧连接状态彻底清理完成。设备搜索与连接调用 WifiP2pManager.discoverPeers 开启设备搜索收到 WIFI_P2P_PEERS_CHANGED_ACTION 广播后调用 WifiP2pManager.requestPeers 获取设备列表调用 WifiP2pManager.connect(MAC) 向指定的 MAC 地址发起连接请求。连接成功与服务启动收到 WIFI_P2P_CONNECTION_CHANGED_ACTION 广播确认 P2P 网络连接成功启动客户端通信服务 start Client(IP,Port)最后返回 P2pConnect Success完成整个连接。3.3.2 方案二 Phone Manual Connect方案二相比方案一省去 Discover MAC 匹配步骤在已知 SSID/密码/信道时可更快建联不足的是此方案需要 Android Q。方案二通过预先指定 P2P 网络名称SSID、密码及信道参数跳过了方案一中漫长且不稳定的“设备扫描discoverPeers与广播回调requestPeers”过程实现了从配置构建到发起连接connect的一步直连大幅提升了 P2P 建连的响应速度和连接成功率差异总结如下表对比维度方案一传统 MAC 模式方案二网络名称直连模式关键步骤discoverPeers - 监听广播 - requestPeers - MAC 连接传入完整 Wi-Fi 参数 - 构建包含 SSID/密码的 WifiP2pConfig连接时延较长。需要经历 Peer 搜索与设备列表更新的广播等待受周围无线环境干扰大。极短。省略了扫描设备和获取 Peer 列表的过程直接发起 P2P 连接。稳定性与成功率容易受阻。若扫描阶段未发现目标设备后续连接将直接失败。高。只要已知目标 P2P 网络的具体配置参数SSID/密码/信道即可跳过搜寻直连。3.3.3 方案三 Phone GO方案三则将GO角色切换为手机由手机创建 P2P 网络眼镜作为 Client 主动加入该方案可降低眼镜侧 Wi-Fi P2P 建组复杂度便于统一管理网络参数。但由于此方案与前两个方案AUTO / MANUAL的差异较大Phone GO是改为由手机建立 P2P 组再 BT 通知眼镜开 WiFi 并加入于是本方案基于第 2 节 AI 眼镜直播流程图作为对比输出。方案三由手机主动创建 Wi-Fi P2P Group担任 Group OwnerGO眼镜通过蓝牙获取手机下发的 Wi-Fi 配置参数SSID、密码、信道等后主动开启 Wi-Fi 并连接手机创建的 P2P 网络手机无需进行设备扫描discoverPeers和 Peer 列表获取requestPeers而是先完成 GO 创建再等待眼镜接入实现稳定、快速的 P2P 建连。对比维度方案二Phone Manual Connect方案三Phone GOGO角色眼镜作为 GO手机作为 GO建网方式手机主动连接眼镜手机主动创建 Group等待眼镜连接是否 discoverPeers否否是否 requestPeers否否Wi-Fi 参数眼镜提供 SSID、密码、信道手机生成 SSID、密码、信道并下发给眼镜建连流程手机 connect 到眼镜手机 createGroup眼镜主动加入建连速度快快稳定性高高适用场景眼镜长期作为视频源手机作为直播中心更便于统一管理网络和后续业务连接3.3.4 方案异同点对于三种 P2P 连接方案手机在给眼镜发送开启 Wi-Fi 指令时都是调用 sendWifiOnCmd通过 isSupport5g 指定是否使用 5G 频段channel 指定具体信道等并通过 wifiConnectType 区分连接方案类型。因此眼镜侧开启 Wi-Fi 的流程保持一致仅根据不同的连接类型执行对应的建连逻辑。fun sendWifiOnCmd( isSupport5g: Int, channel: Int, ssid: String, password: String, wifiConnectType: WifiConnectType )不同的是各方案的 P2P 建立方式存在明显差异方案一Phone Auto Connect传统 MAC 连接手机通过 discoverPeers 搜索周围 P2P 设备获取 Peer 列表后再根据目标设备的 MAC 地址调用 connect 发起连接该方案依赖设备发现及广播回调建连时延较长容易受到无线环境影响。方案二Phone Manual Connect眼镜作为 Group OwnerGO手机提前获取眼镜广播的 SSID、密码及信道等参数直接构建 WifiP2pConfig 发起连接省略设备扫描及 Peer 获取过程连接速度和稳定性均优于方案一。方案三Phone GO手机主动创建 P2P Group 并作为 Group OwnerGO通过蓝牙将 SSID、密码、信道等网络配置下发给眼镜眼镜主动连接手机创建的 P2P 网络手机无需执行设备扫描仅需等待眼镜加入后建立 Socket 通信更适合作为直播、音视频等业务的数据中心。三种方案本质上均基于 Android Wi-Fi P2P 框架实现区别主要体现在Group Owner 的角色分配、P2P 网络建立方式以及网络参数的获取来源随着方案从一到三演进逐步减少了对设备扫描和广播回调的依赖使 P2P 建连流程更加可控显著降低了建连时延提高了连接成功率和整体稳定性。3.3.5 WifiP2pConfig 讨论1P2pFrequencyHelper在 Phone GO 模式下WifiP2pManager.createGroup() 需要指定 P2P Group 的工作频率实际测试发现不同国家和地区支持的 Wi-Fi 信道存在较大差异例如欧洲/日本对 5.8GHz 高频段信道有严格监管而中国常用的 153 信道在部分海外地区可能无法发包如果固定使用同一信道部分手机与眼镜组合会出现概率性的 P2P 建连失败。因此引入P2pFrequencyHelper统一管理 P2P 工作频率通过按照Wi-Fi Country Code - Network Country - SIM Country的多级优先级获取设备所在国家动态选择合适的 Wi-Fi 信道再将其转换为 Android 系统所需的 MHz 频率供 WifiP2pConfig.setGroupOperatingFrequency 使用。/** * Description: P2P 频率助手类 * CreateDate: 2026/7/21 10:46 * Author: agg */ object P2pFrequencyHelper { const val FREQ_5G_153_CHINA 153 // 国内默认153信道 (5765 MHz) const val FREQ_5G_36_GLOBAL 36 // 境外/全球安全36信道 (5180 MHz) const val FREQ_2G_CHANNEL 6 // 2.4G 默认信道号6信道 (2437 MHz) private const val TAG P2pFrequencyHelper RequiresApi(Build.VERSION_CODES.Q) fun buildWifiP2pConfig( context: Context, networkName: String, passphrase: String, channelFrequency: Int ): WifiP2pConfig WifiP2pConfig.Builder().setNetworkName(networkName).setPassphrase(passphrase).apply { if (getBestCountryCode(context).equals(jp, ignoreCase true)) { // 兼容日本创建5G P2P群组按频段自动配置保证5G也增强信道兼容性 logI(TAG, buildWifiP2pConfig Auto 5G for JP country) setGroupOperatingBand(WifiP2pConfig.GROUP_OWNER_BAND_5GHZ) } else if (channelFrequency 0) { // setGroupOperatingFrequency 设置信道的方案与setGroupOperatingBand不能同时使用否则会崩溃 logI(TAG, buildWifiP2pConfig setGroupOperatingFrequency$channelFrequency) setGroupOperatingFrequency(channelFrequency) } else { logI(TAG, buildWifiP2pConfig default 5G) setGroupOperatingBand(WifiP2pConfig.GROUP_OWNER_BAND_5GHZ) } }.build() /** * 将 Wi-Fi 信道号转换为频率MHz * param channel Wi-Fi 信道号 * return 对应的频率MHz若信道号不合法则返回 0 */ fun channelToFrequency(channel: Int): Int { if (channel in 1..13) { return 2412 (channel - 1) * 5 } else if (channel in 34..165) { return 5170 (channel - 34) * 5 } return 0 } /** * 获取适合当前国家/地区的 5G P2P 频段 */ fun getP2pOperatingFrequency(context: Context): Int { val countryCode getBestCountryCode(context) logI(TAG, getP2pOperatingFrequency: countryCode$countryCode) return if (countryCode.equals(cn, ignoreCase true)) { // 1、只有明确在国内(CN)时才使用 5765 MHz (153信道) FREQ_5G_153_CHINA // // 2、日本 (JP)为了规避 W52 户外违规以及 DFS 导致 GO 创建失败的问题强制使用 2.4GHz 保底——在日本验证不成功 // } else if (countryCode.equals(jp, ignoreCase true)) { // FREQ_2G_CHANNEL } else { // 3、其他所有国家以及无法获取国家码时统一兜底使用 5180 MHz (36信道) FREQ_5G_36_GLOBAL } } /** * 多层级精准获取国家码 */ fun getBestCountryCode(context: Context): String { // 1. 优先获取 Wi-Fi 驱动当前的实际国家码最精准反映了 802.11d 广播和芯片实时状态 val wifiCountry getWifiCountryCode(context) if (wifiCountry.isNotEmpty()) { return wifiCountry } val telephonyManager context.getSystemService(Context.TELEPHONY_SERVICE) as? TelephonyManager // 2. 其次读取当前基站/网络国家码反映设备当前物理所在的国家 val networkCountry telephonyManager?.networkCountryIso logI(TAG, getBestCountryCode: networkCountryIso$networkCountry) if (!networkCountry.isNullOrEmpty()) { return networkCountry.lowercase() } // 3. 读取 SIM 卡发行国判断是否为中国卡 val simCountry telephonyManager?.simCountryIso logI(TAG, 3 getBestCountryCode: simCountryIso$simCountry) if (!simCountry.isNullOrEmpty()) { return simCountry.lowercase() } // 4. 无法获取任何网络/SIM卡信息时如纯 Wi-Fi 平板/无卡/开飞行模式返回空字符串 // 外部逻辑会将其判断为非 CN安全兜底到 5180 MHz return } /** * 通过反射读取 Android 底层 Wi-Fi 芯片的 CountryCode */ private fun getWifiCountryCode(context: Context): String { try { val wifiManager context.applicationContext.getSystemService(Context.WIFI_SERVICE) as? WifiManager if (wifiManager ! null) { val method wifiManager.javaClass.getMethod(getCountryCode) val countryCode method.invoke(wifiManager) as? String if (!countryCode.isNullOrEmpty()) { return countryCode.lowercase() } } } catch (_: Exception) { // 部分厂商 ROM 封堵了此隐藏 API 或抛出 SecurityException安全忽略即可 } return } }P2pFrequencyHelper 的核心优势在于默认信道选择国内默认使用5GHz Channel 153日本默认使用5GHz 按频段自动配置其他国家默认使用5GHz Channel 36若设备不支持 5GHz则使用2.4GHz Channel 6信道转换将 Wi-Fi Channel 转换为 Android WifiP2pConfig 所需的工作频率例如 Channel 153 - 5765 MHzChannel 36 - 5180 MHzChannel 6 - 2437 MHz。2setGroupOperatingBand 与 setGroupOperatingFrequency在 API 29 (Android 10) 及以上版本中Android 官方在 WifiP2pConfig.Builder 中新增了setGroupOperatingBand(WifiP2pConfig.GROUP_OWNER_BAND_5GHZ)方法允许开发者直接指定按频段自动配置创建 5G P2P 群组不过在实践和演进过程中这两个 API 有两个坑点需要注意。不能同时调用setGroupOperatingBand指定粗粒度频段与 setGroupOperatingFrequency指定细粒度频率在 Android 系统框架及底层 wpa_supplicant 中存在逻辑互斥同时配置了会导致应用崩溃手动动态指定频率Frequency优于直接强设频段Band因为直接强设 5G Band 存在严重的兼容性缺陷比如DFS雷达信道避让问题、国产 ROM 如小米的系统级 Bug 等。4. ⚛️ 手机实时预览实现实时预览Live Preview是检验端到端延迟与传输稳定性的核心功能为避免阻塞主线程并保证播放流畅度手机端采用了 “生产者-消费者” 线程池队列方案主要通过MediaCodec硬解码 H.264 视频流、并利用SurfaceView实现低延迟渲染使用AudioTrack播放 PCM 音频流。4.1 视频预览视频解码使用 Android 系统自带的 MediaCodec 硬解码器video/avc采用异步回调 MediaCodec.Callback() 模式管理输入 Buffer。在 releaseOutputBuffer(index, true) 中传入 trueMediaCodec 会直接将解码后的 YUV 数据推送到 configure 时绑定的 Surface 上实现零拷贝Zero-Copy渲染大幅降低 CPU 开销与延迟。//创建解码器 H264的Type为 AVC mediaCodec MediaCodec.createDecoderByType(video/avc) mediaCodec.setCallback(object : MediaCodec.Callback() { override fun onInputBufferAvailable(mediaCodec: MediaCodec, i: Int) { inputBufferQueue.put(i) } override fun onOutputBufferAvailable( mediaCodec: MediaCodec, i: Int, bufferInfo: MediaCodec.BufferInfo ) { if (state State.UNINITIALIZED) { return } try { mediaCodec.releaseOutputBuffer(i, true) } catch (e: Exception) { e.printStackTrace() } } override fun onError(mediaCodec: MediaCodec, e: MediaCodec.CodecException) { } override fun onOutputFormatChanged( mediaCodec: MediaCodec, mediaFormat: MediaFormat ) { } }) //创建配置 val mediaFormat MediaFormat.createVideoFormat(video/avc, 1280, 720) //设置解码预期的帧速率【以帧/秒为单位的视频格式的帧速率的键】 mediaFormat.setInteger(MediaFormat.KEY_FRAME_RATE, 25) //配置绑定mediaFormat和surface mediaCodec!!.configure(mediaFormat, surface, null, 0)由于接收的是网络裸流VideoRunnable 线程充当消费者负责从 frameBlockingQueue 中取出 H.264 帧并控制 25 FPS 的平滑播放节奏inner class VideoRunnable : Runnable { override fun run() { while (threadRunning) { if (frameBlockingQueue.isNotEmpty() inputBufferQueue.isNotEmpty()) { val i inputBufferQueue.poll() val data frameBlockingQueue.poll() if (data ! null) { val currentTime System.currentTimeMillis() val sleepTime: Long FRAME_INTERVAL - (currentTime - lastFrameTime) if (sleepTime 0) { try { Thread.sleep(sleepTime) } catch (e: InterruptedException) { throw RuntimeException(e) } } if (i ! null state State.RUNNING) { try { val codecInputBuffer mediaCodec.getInputBuffer(i) codecInputBuffer!!.clear() codecInputBuffer.put(data) mediaCodec.queueInputBuffer(i, 0, data.size, 1, 0) lastFrameTime System.currentTimeMillis() } catch (e:Exception) { logE(TAG,VideoRunnable Exception : ${e.printStackTrace()}) } } } } } } }4.2 音频播放音频解码部分针对特定的压缩格式如 WQ 压缩格式进行了解包还原为 16kHz 单声道 16Bit 的 PCM 裸流并通过 AudioTrack.MODE_STREAM 模式实时写入音频缓冲区private fun initAudioTrack() { // AudioTrack 得到播放最小缓冲区的大小 minBufSize AudioTrack.getMinBufferSize( 16000, // 设置音频数据的采样率 AudioFormat.CHANNEL_OUT_MONO, // 设置输出声道CHANNEL_OUT_MONO单声道 AudioFormat.ENCODING_PCM_16BIT ) // 设置音频数据块是8位还是16位这里设置为16位 // 实例化播放音频对象 audioTrack AudioTrack( AudioAttributes.Builder() .setUsage(AudioAttributes.USAGE_MEDIA) .setContentType(AudioAttributes.CONTENT_TYPE_MUSIC) .build(), AudioFormat.Builder().setSampleRate(16000) .setEncoding(AudioFormat.ENCODING_PCM_16BIT) .setChannelMask(AudioFormat.CHANNEL_OUT_MONO) .build(), minBufSize, AudioTrack.MODE_STREAM, AudioManager.AUDIO_SESSION_ID_GENERATE ) } inner class AudioRunnable : Runnable { override fun run() { while (threadRunning) { if (audioBlockingQueue.isNotEmpty()) { val bytes audioBlockingQueue.poll() if (bytes ! null) { audioBuffer.clear() SpeechFormatUtils.unpackWQ(bytes).forEach { pcm - audioBuffer.write(pcm) } val audioData audioBuffer.readByteArray() if (state State.RUNNING) { audioTrack!!.write(audioData, 0, audioData.size) } } } } } }5. ✅ 手机推流概述手机直播推流模块是系统连接眼镜端音视频采集与云端直播平台的核心桥梁该功能核心是由 LiveClientTask 单例类统一管理集成了网络通信、硬件解码、音视频数据重组以及腾讯云直播 SDKV2TXLivePusher等模块。整个推流过程在数据传输、处理部分与手机实时预览的方案一致参考第四章节核心不同在于手机实时预览是本地播放音视频手机推流是推送音视频给腾讯云直播 SDK。5.1 腾讯直播 SDK 初始化与参数配置推流器使用 V2TXLivePusherImpl 实现针对眼镜端采集特性开启了自定义音视频采集模式并设置了 1280x720 720P 横屏码率自适应编码。自定义采集开启调用 enableCustomAudioCapture(true) 和 enableCustomVideoCapture(true) 拦截默认摄像头/麦克风输入视频编码参数设置如下mLivePusher.setVideoQuality( V2TXLiveDef.V2TXLiveVideoEncoderParam(V2TXLiveDef.V2TXLiveVideoResolution.V2TXLiveVideoResolution1280x720).apply { videoBitrate 2200 minVideoBitrate 1500 videoResolutionMode V2TXLiveDef.V2TXLiveVideoResolutionMode.V2TXLiveVideoResolutionModeLandscape } )5.2 视频推送视频帧写入 MediaCodec 后在 MediaCodec.Callback 的 onOutputBufferAvailable 回调中将输出的 YUV420 数据提取封装为 V2TXLiveVideoFrame 格式推送到 SDKval videoFrame V2TXLiveDef.V2TXLiveVideoFrame().apply { pixelFormat V2TXLiveDef.V2TXLivePixelFormat.V2TXLivePixelFormatI420 bufferType V2TXLiveDef.V2TXLiveBufferType.V2TXLiveBufferTypeByteArray data yuvData width 1280 height 720 } mLivePusher.sendCustomVideoFrame(videoFrame)5.3 音频推送mLivePusher.sendCustomAudioFrame(V2TXLiveAudioFrame().apply { data audioData channel 1 sampleRate 16000 })5.4 房间管理、心跳与弹幕交互建房与推流会话建立后异步调用 LiveRepository.createRoom() 创建房间成功后获取 pushUrl 并执行 V2TXLivePusher.startPush(pushUrl) 开启推流封面抓取与心跳维持推流启动 5 秒后通过 V2TXLivePusher.snapshot() 截取画面上传作为直播封面并启动 Handler 定时器每 4 分钟发送 LIVE_ROOM_HEART_BEAT 心跳IM 互动弹幕反馈通过 V2TIMManager 加入直播群组监听群成员进入onMemberEnter和文本弹幕onRecvGroupTextMessage将消息处理截断后通过蓝牙/局域网信道反向发送给眼镜端实现眼镜端的实时弹幕提醒。 小结本方案基于双芯片物理隔离架构在眼镜端由 STM32N6Camera与物奇芯片Audio协同完成 H.264/Opus 原生采集、硬件压缩与底层 3A 降噪同时系统通过 BLE/BT 通道进行信令控制与 Socket 参数协商配合智能信道适配P2pFrequencyHelper建立高带宽 Wi-Fi P2P 直连克服了 RTOS 设备的网络协议栈与高功耗传输瓶颈。手机端引入“生产者-消费者”线程队列进行解耦利用 MediaCodec 硬解码与 SurfaceView 实现零拷贝低延迟本地预览同时接入腾讯云直播 SDKV2TXLivePusher完成 720P 码率自适应推流并打通 IM 弹幕反向回传至眼镜端实现了第一视角POV直播的全链路闭环。另外由于本人能力有限如有错误敬请批评指正谢谢。 AR 眼镜之-直播-技术方案
目录 前言直播技术框图 1. AI 眼镜数据源概述1.1 硬件分工与音视频采集1.2 跨芯片传输与无线输出链路2. AI 眼镜直播流程概述3. Wi-Fi P2P 连接方案讨论3.1 相关概念3.2 P2P/IP/TCP/Socket3.3 三种 P2P 连接方案3.3.1 方案一 Phone Auto Connect3.3.2 方案二 Phone Manual Connect3.3.3 方案三 Phone GO3.3.4 方案异同点3.3.5 WifiP2pConfig 讨论1P2pFrequencyHelper2setGroupOperatingBand 与 setGroupOperatingFrequency4. ⚛️ 手机实时预览实现4.1 视频预览4.2 音频播放5. ✅ 手机推流概述5.1 腾讯直播 SDK 初始化与参数配置5.2 视频推送5.3 音频推送5.4 房间管理、心跳与弹幕交互 小结 前言随着可穿戴设备与人工智能技术的深度融合基于 RTOS实时操作系统的轻量化 AI 眼镜正逐渐成为第一视角POV实时直播与交互的重要终端RTOS 平台具备极致的低功耗、快速启动和高实时性优势但受限于硬件资源与功耗预算其在音视频编码、复杂网络协议栈处理及长距离无线传输方面面临天然挑战为突破上述瓶颈本技术方案设计并实现了一套“AI 眼镜采集 — 手机中枢处理 — 云端分发互动”的三端协同直播架构AI 眼镜端AI Glass采用低功耗双芯片物理隔离架构STM32N6 主控挂载 Camera 完成画面采集与 H.264/MJPEG 硬件压缩物奇 WuQi 芯片处理麦克风阵列数据及 3A 降噪算法输出 Opus 音频流通过板载 I2S/UART 高速总线进行跨芯片数据汇聚手机端Phone作为中转与控制中枢基于“蓝牙信令控制 Wi-Fi P2P 高带宽传输”的双通道握手机制建链利用“生产者-消费者”异步线程队列与 MediaCodec 硬解码实现本地零拷贝低延迟预览同时集成腾讯云直播 SDKV2TXLivePusher进行横屏码率自适应推流云端Cloud基于直播云平台如腾讯云完成音视频流的转码、存储与 CDN 全网分发结合 IM 互动系统将弹幕消息实时反向回传至眼镜端形成完整的闭环体验。直播技术框图下图为系统的整体技术架构框图概述了各模块间的分工、协议传输与数据流向。 1. AI 眼镜数据源概述本方案基于RTOS AI 眼镜的双芯片硬件架构在进行手机端直播与推流前眼镜端负责完成音视频的原生采集、前级处理以及跨芯片的同步传输等。1.1 硬件分工与音视频采集眼镜端采用低功耗双芯片架构音频与视频采集物理隔离视频源STM32N6 主控 负责挂载 Camera 模块采集画面并进行硬件压缩输出H264 / MJPEG视频帧。音频源物奇 WuQi 芯片 负责麦克风阵列的数据捕获经底层 3A 算法降噪、回声消除处理后输出Opus音频流。1.2 跨芯片传输与无线输出链路由于音视频挂载在不同芯片上系统根据不同的无线连接场景在眼镜内部通过高速物理总线I2S / UART进行一级数据汇聚最终通过 Wi-Fi 或蓝牙BT将数据流交付给手机端无线模式眼镜端内部流向与无线输出Wi-Fi 模式视频STM32N6 → Wi-Fi → 手机端音频物奇 (Audio) → I2S 总线 → STM32N6 → Wi-Fi → 手机端BT 蓝牙模式视频STM32N6 (Video) → UART 串口 → 物奇 → 蓝牙 → 手机端音频物奇 (Audio) → 蓝牙 → 手机端注本文主要阐述 Wi-Fi 模式BT 模式就不在此赘述。2. AI 眼镜直播流程概述本方案采用 “蓝牙信令控制 Wi-Fi P2P 高带宽传输” 的双通道架构同时手机端通过蓝牙动态获取眼镜端的 Socket 接口IP/Port实现了无缝的 P2P 直连建链。初始化Bluetooth 交互指令触发用户在眼镜端发起直播眼镜通过蓝牙通道向手机发送开启直播控制指令任务初始化手机蓝牙模块接收指令并创建直播本地任务同时通过蓝牙指令唤醒眼镜 Wi-Fi并拉取眼镜 Wi-Fi 的 MAC、IP、Port 信息。网络建立与数据传输通道建链Wi-Fi P2P / Socket网络建立手机蓝牙模块向 Wi-Fi 模块发起连接网络连接数据传输通道建链Wi-Fi 模块完成 P2P 点对点握手 与 Socket 数据通道建链同时通过蓝牙模块通知眼镜直播开启成功。音视频推流与处理Wi-Fi 高速通道推流眼镜通过 Wi-Fi 通道开始高速推送音视频流分发与渲染手机网络层接收流数据并分发至 App 业务层进行解码、播放以及转推至 CDN。3. Wi-Fi P2P 连接方案讨论3.1 相关概念概念定义在 AI 眼镜 P2P 场景中的作用P2P(Peer-to-Peer)点对点通信方式设备之间直接建立连接进行数据交换实现手机与 AI 眼镜直接通信用于传输音视频和控制数据Wi-Fi P2P(Wi-Fi Direct)基于 Wi-Fi 的设备直连技术无需依赖路由器提供手机与眼镜之间高速、低延迟的数据传输链路GO(Group Owner)Wi-Fi P2P 网络中的管理设备类似 Wi-Fi 热点角色创建 P2P 网络并管理 Client 设备接入GC(Group Client)加入 Wi-Fi P2P 网络的设备连接 GO获取网络信息后与对端进行通信SSIDWi-Fi 网络名称用于标识无线网络标识 P2P 网络例如 DIRECT-P2P-A1B2用于设备发现和连接MAC 地址网络设备的硬件唯一标识蓝牙发现设备时使用并用于生成 P2P SSID例如 DIRECT-P2P-A1B2Band(频段)表示 Wi-Fi 工作在哪个频段决定在哪个频率范围工作例如 5GHz 或 2.4GHzChannel(信道)表示频段下面的多个信道决定该频段中的具体信道例如 5GHz Channel 153 或 2.4GHz Channel 6goIntent(Group Owner Intent)希望自己成为 GO 的意愿值取值范围 0~15数值越大越希望自己成为 GO默认值 2 是倾向做ClientIP 地址网络中设备的唯一地址用于设备定位Wi-Fi P2P 建立后通过 IP 地址找到手机或眼镜设备Port(端口)用于区分设备上的不同网络服务区分视频、音频、控制等不同 Socket 服务TCP可靠传输协议保证数据完整和顺序用于传输控制指令、配置数据等可靠性要求高的数据UDP面向实时传输的协议延迟较低用于传输实时音视频数据降低直播延迟Socket应用程序进行网络通信的接口手机 App 与眼镜通过 Socket 建立连接实现数据收发3.2 P2P/IP/TCP/Socket咱们一起回顾下P2P、IP、TCP、Socket等关键技术在 OSI 七层模型的联系。在OSI模型中物理层和链路层的“Wi-Fi P2P”打通设备直连网络层的“IP”负责寻址定位传输层的“TCP”确保数据可靠送达而会话层的“Socket”则作为它们与应用层之间的通信接口共同支撑了上层音视频和控制数据的稳定传输。3.3 三种 P2P 连接方案本节的核心内容是对第 2 节 AI 眼镜直播流程图Wi-Fi Connect部分的细化基于手机 App 与 AI 眼镜之间通过 Wi-Fi P2P 进行直连目前调研并完成联调实现了三种连接方案眼镜作为 GO手机自动连接眼镜Phone Auto Connect眼镜作为 GO手机手动连接Phone Manual Connect手机作为 GO眼镜手动连接Phone GO3.3.1 方案一 Phone Auto Connect第 2 节 AI 眼镜直播流程图采用的方案一手机 App 自动发现眼镜并主动建立 Wi-Fi P2P 连接连接成功后通过 Socket 进行音视频数据传输。清理与重置环境调用 WifiP2pManager.removeGroup 移除已有的历史组网内部延迟300ms确保旧连接状态彻底清理完成。设备搜索与连接调用 WifiP2pManager.discoverPeers 开启设备搜索收到 WIFI_P2P_PEERS_CHANGED_ACTION 广播后调用 WifiP2pManager.requestPeers 获取设备列表调用 WifiP2pManager.connect(MAC) 向指定的 MAC 地址发起连接请求。连接成功与服务启动收到 WIFI_P2P_CONNECTION_CHANGED_ACTION 广播确认 P2P 网络连接成功启动客户端通信服务 start Client(IP,Port)最后返回 P2pConnect Success完成整个连接。3.3.2 方案二 Phone Manual Connect方案二相比方案一省去 Discover MAC 匹配步骤在已知 SSID/密码/信道时可更快建联不足的是此方案需要 Android Q。方案二通过预先指定 P2P 网络名称SSID、密码及信道参数跳过了方案一中漫长且不稳定的“设备扫描discoverPeers与广播回调requestPeers”过程实现了从配置构建到发起连接connect的一步直连大幅提升了 P2P 建连的响应速度和连接成功率差异总结如下表对比维度方案一传统 MAC 模式方案二网络名称直连模式关键步骤discoverPeers - 监听广播 - requestPeers - MAC 连接传入完整 Wi-Fi 参数 - 构建包含 SSID/密码的 WifiP2pConfig连接时延较长。需要经历 Peer 搜索与设备列表更新的广播等待受周围无线环境干扰大。极短。省略了扫描设备和获取 Peer 列表的过程直接发起 P2P 连接。稳定性与成功率容易受阻。若扫描阶段未发现目标设备后续连接将直接失败。高。只要已知目标 P2P 网络的具体配置参数SSID/密码/信道即可跳过搜寻直连。3.3.3 方案三 Phone GO方案三则将GO角色切换为手机由手机创建 P2P 网络眼镜作为 Client 主动加入该方案可降低眼镜侧 Wi-Fi P2P 建组复杂度便于统一管理网络参数。但由于此方案与前两个方案AUTO / MANUAL的差异较大Phone GO是改为由手机建立 P2P 组再 BT 通知眼镜开 WiFi 并加入于是本方案基于第 2 节 AI 眼镜直播流程图作为对比输出。方案三由手机主动创建 Wi-Fi P2P Group担任 Group OwnerGO眼镜通过蓝牙获取手机下发的 Wi-Fi 配置参数SSID、密码、信道等后主动开启 Wi-Fi 并连接手机创建的 P2P 网络手机无需进行设备扫描discoverPeers和 Peer 列表获取requestPeers而是先完成 GO 创建再等待眼镜接入实现稳定、快速的 P2P 建连。对比维度方案二Phone Manual Connect方案三Phone GOGO角色眼镜作为 GO手机作为 GO建网方式手机主动连接眼镜手机主动创建 Group等待眼镜连接是否 discoverPeers否否是否 requestPeers否否Wi-Fi 参数眼镜提供 SSID、密码、信道手机生成 SSID、密码、信道并下发给眼镜建连流程手机 connect 到眼镜手机 createGroup眼镜主动加入建连速度快快稳定性高高适用场景眼镜长期作为视频源手机作为直播中心更便于统一管理网络和后续业务连接3.3.4 方案异同点对于三种 P2P 连接方案手机在给眼镜发送开启 Wi-Fi 指令时都是调用 sendWifiOnCmd通过 isSupport5g 指定是否使用 5G 频段channel 指定具体信道等并通过 wifiConnectType 区分连接方案类型。因此眼镜侧开启 Wi-Fi 的流程保持一致仅根据不同的连接类型执行对应的建连逻辑。fun sendWifiOnCmd( isSupport5g: Int, channel: Int, ssid: String, password: String, wifiConnectType: WifiConnectType )不同的是各方案的 P2P 建立方式存在明显差异方案一Phone Auto Connect传统 MAC 连接手机通过 discoverPeers 搜索周围 P2P 设备获取 Peer 列表后再根据目标设备的 MAC 地址调用 connect 发起连接该方案依赖设备发现及广播回调建连时延较长容易受到无线环境影响。方案二Phone Manual Connect眼镜作为 Group OwnerGO手机提前获取眼镜广播的 SSID、密码及信道等参数直接构建 WifiP2pConfig 发起连接省略设备扫描及 Peer 获取过程连接速度和稳定性均优于方案一。方案三Phone GO手机主动创建 P2P Group 并作为 Group OwnerGO通过蓝牙将 SSID、密码、信道等网络配置下发给眼镜眼镜主动连接手机创建的 P2P 网络手机无需执行设备扫描仅需等待眼镜加入后建立 Socket 通信更适合作为直播、音视频等业务的数据中心。三种方案本质上均基于 Android Wi-Fi P2P 框架实现区别主要体现在Group Owner 的角色分配、P2P 网络建立方式以及网络参数的获取来源随着方案从一到三演进逐步减少了对设备扫描和广播回调的依赖使 P2P 建连流程更加可控显著降低了建连时延提高了连接成功率和整体稳定性。3.3.5 WifiP2pConfig 讨论1P2pFrequencyHelper在 Phone GO 模式下WifiP2pManager.createGroup() 需要指定 P2P Group 的工作频率实际测试发现不同国家和地区支持的 Wi-Fi 信道存在较大差异例如欧洲/日本对 5.8GHz 高频段信道有严格监管而中国常用的 153 信道在部分海外地区可能无法发包如果固定使用同一信道部分手机与眼镜组合会出现概率性的 P2P 建连失败。因此引入P2pFrequencyHelper统一管理 P2P 工作频率通过按照Wi-Fi Country Code - Network Country - SIM Country的多级优先级获取设备所在国家动态选择合适的 Wi-Fi 信道再将其转换为 Android 系统所需的 MHz 频率供 WifiP2pConfig.setGroupOperatingFrequency 使用。/** * Description: P2P 频率助手类 * CreateDate: 2026/7/21 10:46 * Author: agg */ object P2pFrequencyHelper { const val FREQ_5G_153_CHINA 153 // 国内默认153信道 (5765 MHz) const val FREQ_5G_36_GLOBAL 36 // 境外/全球安全36信道 (5180 MHz) const val FREQ_2G_CHANNEL 6 // 2.4G 默认信道号6信道 (2437 MHz) private const val TAG P2pFrequencyHelper RequiresApi(Build.VERSION_CODES.Q) fun buildWifiP2pConfig( context: Context, networkName: String, passphrase: String, channelFrequency: Int ): WifiP2pConfig WifiP2pConfig.Builder().setNetworkName(networkName).setPassphrase(passphrase).apply { if (getBestCountryCode(context).equals(jp, ignoreCase true)) { // 兼容日本创建5G P2P群组按频段自动配置保证5G也增强信道兼容性 logI(TAG, buildWifiP2pConfig Auto 5G for JP country) setGroupOperatingBand(WifiP2pConfig.GROUP_OWNER_BAND_5GHZ) } else if (channelFrequency 0) { // setGroupOperatingFrequency 设置信道的方案与setGroupOperatingBand不能同时使用否则会崩溃 logI(TAG, buildWifiP2pConfig setGroupOperatingFrequency$channelFrequency) setGroupOperatingFrequency(channelFrequency) } else { logI(TAG, buildWifiP2pConfig default 5G) setGroupOperatingBand(WifiP2pConfig.GROUP_OWNER_BAND_5GHZ) } }.build() /** * 将 Wi-Fi 信道号转换为频率MHz * param channel Wi-Fi 信道号 * return 对应的频率MHz若信道号不合法则返回 0 */ fun channelToFrequency(channel: Int): Int { if (channel in 1..13) { return 2412 (channel - 1) * 5 } else if (channel in 34..165) { return 5170 (channel - 34) * 5 } return 0 } /** * 获取适合当前国家/地区的 5G P2P 频段 */ fun getP2pOperatingFrequency(context: Context): Int { val countryCode getBestCountryCode(context) logI(TAG, getP2pOperatingFrequency: countryCode$countryCode) return if (countryCode.equals(cn, ignoreCase true)) { // 1、只有明确在国内(CN)时才使用 5765 MHz (153信道) FREQ_5G_153_CHINA // // 2、日本 (JP)为了规避 W52 户外违规以及 DFS 导致 GO 创建失败的问题强制使用 2.4GHz 保底——在日本验证不成功 // } else if (countryCode.equals(jp, ignoreCase true)) { // FREQ_2G_CHANNEL } else { // 3、其他所有国家以及无法获取国家码时统一兜底使用 5180 MHz (36信道) FREQ_5G_36_GLOBAL } } /** * 多层级精准获取国家码 */ fun getBestCountryCode(context: Context): String { // 1. 优先获取 Wi-Fi 驱动当前的实际国家码最精准反映了 802.11d 广播和芯片实时状态 val wifiCountry getWifiCountryCode(context) if (wifiCountry.isNotEmpty()) { return wifiCountry } val telephonyManager context.getSystemService(Context.TELEPHONY_SERVICE) as? TelephonyManager // 2. 其次读取当前基站/网络国家码反映设备当前物理所在的国家 val networkCountry telephonyManager?.networkCountryIso logI(TAG, getBestCountryCode: networkCountryIso$networkCountry) if (!networkCountry.isNullOrEmpty()) { return networkCountry.lowercase() } // 3. 读取 SIM 卡发行国判断是否为中国卡 val simCountry telephonyManager?.simCountryIso logI(TAG, 3 getBestCountryCode: simCountryIso$simCountry) if (!simCountry.isNullOrEmpty()) { return simCountry.lowercase() } // 4. 无法获取任何网络/SIM卡信息时如纯 Wi-Fi 平板/无卡/开飞行模式返回空字符串 // 外部逻辑会将其判断为非 CN安全兜底到 5180 MHz return } /** * 通过反射读取 Android 底层 Wi-Fi 芯片的 CountryCode */ private fun getWifiCountryCode(context: Context): String { try { val wifiManager context.applicationContext.getSystemService(Context.WIFI_SERVICE) as? WifiManager if (wifiManager ! null) { val method wifiManager.javaClass.getMethod(getCountryCode) val countryCode method.invoke(wifiManager) as? String if (!countryCode.isNullOrEmpty()) { return countryCode.lowercase() } } } catch (_: Exception) { // 部分厂商 ROM 封堵了此隐藏 API 或抛出 SecurityException安全忽略即可 } return } }P2pFrequencyHelper 的核心优势在于默认信道选择国内默认使用5GHz Channel 153日本默认使用5GHz 按频段自动配置其他国家默认使用5GHz Channel 36若设备不支持 5GHz则使用2.4GHz Channel 6信道转换将 Wi-Fi Channel 转换为 Android WifiP2pConfig 所需的工作频率例如 Channel 153 - 5765 MHzChannel 36 - 5180 MHzChannel 6 - 2437 MHz。2setGroupOperatingBand 与 setGroupOperatingFrequency在 API 29 (Android 10) 及以上版本中Android 官方在 WifiP2pConfig.Builder 中新增了setGroupOperatingBand(WifiP2pConfig.GROUP_OWNER_BAND_5GHZ)方法允许开发者直接指定按频段自动配置创建 5G P2P 群组不过在实践和演进过程中这两个 API 有两个坑点需要注意。不能同时调用setGroupOperatingBand指定粗粒度频段与 setGroupOperatingFrequency指定细粒度频率在 Android 系统框架及底层 wpa_supplicant 中存在逻辑互斥同时配置了会导致应用崩溃手动动态指定频率Frequency优于直接强设频段Band因为直接强设 5G Band 存在严重的兼容性缺陷比如DFS雷达信道避让问题、国产 ROM 如小米的系统级 Bug 等。4. ⚛️ 手机实时预览实现实时预览Live Preview是检验端到端延迟与传输稳定性的核心功能为避免阻塞主线程并保证播放流畅度手机端采用了 “生产者-消费者” 线程池队列方案主要通过MediaCodec硬解码 H.264 视频流、并利用SurfaceView实现低延迟渲染使用AudioTrack播放 PCM 音频流。4.1 视频预览视频解码使用 Android 系统自带的 MediaCodec 硬解码器video/avc采用异步回调 MediaCodec.Callback() 模式管理输入 Buffer。在 releaseOutputBuffer(index, true) 中传入 trueMediaCodec 会直接将解码后的 YUV 数据推送到 configure 时绑定的 Surface 上实现零拷贝Zero-Copy渲染大幅降低 CPU 开销与延迟。//创建解码器 H264的Type为 AVC mediaCodec MediaCodec.createDecoderByType(video/avc) mediaCodec.setCallback(object : MediaCodec.Callback() { override fun onInputBufferAvailable(mediaCodec: MediaCodec, i: Int) { inputBufferQueue.put(i) } override fun onOutputBufferAvailable( mediaCodec: MediaCodec, i: Int, bufferInfo: MediaCodec.BufferInfo ) { if (state State.UNINITIALIZED) { return } try { mediaCodec.releaseOutputBuffer(i, true) } catch (e: Exception) { e.printStackTrace() } } override fun onError(mediaCodec: MediaCodec, e: MediaCodec.CodecException) { } override fun onOutputFormatChanged( mediaCodec: MediaCodec, mediaFormat: MediaFormat ) { } }) //创建配置 val mediaFormat MediaFormat.createVideoFormat(video/avc, 1280, 720) //设置解码预期的帧速率【以帧/秒为单位的视频格式的帧速率的键】 mediaFormat.setInteger(MediaFormat.KEY_FRAME_RATE, 25) //配置绑定mediaFormat和surface mediaCodec!!.configure(mediaFormat, surface, null, 0)由于接收的是网络裸流VideoRunnable 线程充当消费者负责从 frameBlockingQueue 中取出 H.264 帧并控制 25 FPS 的平滑播放节奏inner class VideoRunnable : Runnable { override fun run() { while (threadRunning) { if (frameBlockingQueue.isNotEmpty() inputBufferQueue.isNotEmpty()) { val i inputBufferQueue.poll() val data frameBlockingQueue.poll() if (data ! null) { val currentTime System.currentTimeMillis() val sleepTime: Long FRAME_INTERVAL - (currentTime - lastFrameTime) if (sleepTime 0) { try { Thread.sleep(sleepTime) } catch (e: InterruptedException) { throw RuntimeException(e) } } if (i ! null state State.RUNNING) { try { val codecInputBuffer mediaCodec.getInputBuffer(i) codecInputBuffer!!.clear() codecInputBuffer.put(data) mediaCodec.queueInputBuffer(i, 0, data.size, 1, 0) lastFrameTime System.currentTimeMillis() } catch (e:Exception) { logE(TAG,VideoRunnable Exception : ${e.printStackTrace()}) } } } } } } }4.2 音频播放音频解码部分针对特定的压缩格式如 WQ 压缩格式进行了解包还原为 16kHz 单声道 16Bit 的 PCM 裸流并通过 AudioTrack.MODE_STREAM 模式实时写入音频缓冲区private fun initAudioTrack() { // AudioTrack 得到播放最小缓冲区的大小 minBufSize AudioTrack.getMinBufferSize( 16000, // 设置音频数据的采样率 AudioFormat.CHANNEL_OUT_MONO, // 设置输出声道CHANNEL_OUT_MONO单声道 AudioFormat.ENCODING_PCM_16BIT ) // 设置音频数据块是8位还是16位这里设置为16位 // 实例化播放音频对象 audioTrack AudioTrack( AudioAttributes.Builder() .setUsage(AudioAttributes.USAGE_MEDIA) .setContentType(AudioAttributes.CONTENT_TYPE_MUSIC) .build(), AudioFormat.Builder().setSampleRate(16000) .setEncoding(AudioFormat.ENCODING_PCM_16BIT) .setChannelMask(AudioFormat.CHANNEL_OUT_MONO) .build(), minBufSize, AudioTrack.MODE_STREAM, AudioManager.AUDIO_SESSION_ID_GENERATE ) } inner class AudioRunnable : Runnable { override fun run() { while (threadRunning) { if (audioBlockingQueue.isNotEmpty()) { val bytes audioBlockingQueue.poll() if (bytes ! null) { audioBuffer.clear() SpeechFormatUtils.unpackWQ(bytes).forEach { pcm - audioBuffer.write(pcm) } val audioData audioBuffer.readByteArray() if (state State.RUNNING) { audioTrack!!.write(audioData, 0, audioData.size) } } } } } }5. ✅ 手机推流概述手机直播推流模块是系统连接眼镜端音视频采集与云端直播平台的核心桥梁该功能核心是由 LiveClientTask 单例类统一管理集成了网络通信、硬件解码、音视频数据重组以及腾讯云直播 SDKV2TXLivePusher等模块。整个推流过程在数据传输、处理部分与手机实时预览的方案一致参考第四章节核心不同在于手机实时预览是本地播放音视频手机推流是推送音视频给腾讯云直播 SDK。5.1 腾讯直播 SDK 初始化与参数配置推流器使用 V2TXLivePusherImpl 实现针对眼镜端采集特性开启了自定义音视频采集模式并设置了 1280x720 720P 横屏码率自适应编码。自定义采集开启调用 enableCustomAudioCapture(true) 和 enableCustomVideoCapture(true) 拦截默认摄像头/麦克风输入视频编码参数设置如下mLivePusher.setVideoQuality( V2TXLiveDef.V2TXLiveVideoEncoderParam(V2TXLiveDef.V2TXLiveVideoResolution.V2TXLiveVideoResolution1280x720).apply { videoBitrate 2200 minVideoBitrate 1500 videoResolutionMode V2TXLiveDef.V2TXLiveVideoResolutionMode.V2TXLiveVideoResolutionModeLandscape } )5.2 视频推送视频帧写入 MediaCodec 后在 MediaCodec.Callback 的 onOutputBufferAvailable 回调中将输出的 YUV420 数据提取封装为 V2TXLiveVideoFrame 格式推送到 SDKval videoFrame V2TXLiveDef.V2TXLiveVideoFrame().apply { pixelFormat V2TXLiveDef.V2TXLivePixelFormat.V2TXLivePixelFormatI420 bufferType V2TXLiveDef.V2TXLiveBufferType.V2TXLiveBufferTypeByteArray data yuvData width 1280 height 720 } mLivePusher.sendCustomVideoFrame(videoFrame)5.3 音频推送mLivePusher.sendCustomAudioFrame(V2TXLiveAudioFrame().apply { data audioData channel 1 sampleRate 16000 })5.4 房间管理、心跳与弹幕交互建房与推流会话建立后异步调用 LiveRepository.createRoom() 创建房间成功后获取 pushUrl 并执行 V2TXLivePusher.startPush(pushUrl) 开启推流封面抓取与心跳维持推流启动 5 秒后通过 V2TXLivePusher.snapshot() 截取画面上传作为直播封面并启动 Handler 定时器每 4 分钟发送 LIVE_ROOM_HEART_BEAT 心跳IM 互动弹幕反馈通过 V2TIMManager 加入直播群组监听群成员进入onMemberEnter和文本弹幕onRecvGroupTextMessage将消息处理截断后通过蓝牙/局域网信道反向发送给眼镜端实现眼镜端的实时弹幕提醒。 小结本方案基于双芯片物理隔离架构在眼镜端由 STM32N6Camera与物奇芯片Audio协同完成 H.264/Opus 原生采集、硬件压缩与底层 3A 降噪同时系统通过 BLE/BT 通道进行信令控制与 Socket 参数协商配合智能信道适配P2pFrequencyHelper建立高带宽 Wi-Fi P2P 直连克服了 RTOS 设备的网络协议栈与高功耗传输瓶颈。手机端引入“生产者-消费者”线程队列进行解耦利用 MediaCodec 硬解码与 SurfaceView 实现零拷贝低延迟本地预览同时接入腾讯云直播 SDKV2TXLivePusher完成 720P 码率自适应推流并打通 IM 弹幕反向回传至眼镜端实现了第一视角POV直播的全链路闭环。另外由于本人能力有限如有错误敬请批评指正谢谢。