简介基于VNC实现的Android局域网飞屏投影server端源码面向Android开发、无线投屏应用学习者解决在无外网环境下通过自建服务实现手机屏幕投影到其他设备的问题。资源包为rar压缩格式大小约217KB共119个文件包含84个java源文件、24个xml配置文件、5个png图标、2个jar库以及工程与配置文件等其中java文件覆盖VNC连接、RFB协议解析、屏幕捕获等核心逻辑xml文件用于界面与交互配置。server端启用互动功能后会以自身IP为名称向局域网广播client设备开启互动即可发现服务端并显示IP用户摇晃手机或点击服务端名称即可完成互联投屏整体交互设计清晰。已有395人学习下载。通过该源码可完整掌握基于VNC的局域网投屏方案理解设备发现、连接握手到屏幕数据转发链路既能作为Android网络编程的实战范本也能在此基础上二次开发桌面控制、多屏互动等扩展功能适合希望深入VNC协议与P2P连接技术的开发者参考。 相信不少做影音集成、智能家居或者电视盒子开发的朋友都遇到过这种需求想把手机上的视频、照片或者电脑里的PPT一键甩到客厅大屏上但偏偏不想经过任何第三方云服务器也不想非得打开某个特定App才能投。这时候一个自建的“飞屏投影server端”就成了最顺手的东西。它本质上是一个跑在电视、盒子或树莓派上的服务进程负责接收手机端主动推过来的媒体流解码后交给显示层输出。这篇东西我会从server端源码的角度出发把整个投屏链路拆开来讲从设备发现、会话建立、码流传输到音画同步再到我实际搭建时踩过的坑一并整理出来。先说结论别看“飞屏”两个字听着玄乎server端代码的核心工作其实就三件事——被手机找到、把码流接住、把画面播出来。真正的复杂度集中在协议细节和异常处理上。我这份源码基于Linux环境开发用C编写服务主体音视频处理走FFmpeg网络层直接操作socket交互信令走JSON。如果你正准备做同类项目或者刚拿到一份投屏server端源码正愁不知道怎么下手照着下面的思路去读代码效率会高很多。1. 项目概述与整体设计思路1.1 飞屏投影server端到底在解决什么问题先把使用场景画清楚。一个典型的飞屏过程是这样的手机和电视处于同一个局域网内手机App通过某种协议发现电视上的server端服务然后发送一个投影请求。server端同意之后手机开始源源不断地把H.264或H.265编码的视频流推到电视端。电视端收到数据后做解码、渲染最终在屏幕上出画面。所以server端源码不是某一个单一功能文件而是一整套链路。它至少包含网络服务模块监听端口处理TCP/UDP连接。协议解析模块识别手机端发来的信令回复对应的握手应答。流媒体接收模块把收到的音视频数据包按顺序组装、去重、丢包重传。解码与渲染模块调用硬件或软件解码器把压缩后的视频帧变成能在屏幕上显示的图像。会话管理模块负责处理“谁在投”“投什么”“投多久”以及异常断开后的资源回收。这五个模块缺一不可。我见过不少半成品源码网络模块写得很扎实但解码和渲染是空的只打印日志不出画面这就是典型的“只知其一不知其二”。真正能跑的server端源码必须把这条路全部走通才算是一个完整的产品。1.2 架构选型为什么这样设计在设计server端时我经过了一段纠结期主要在两种架构之间做选择单线程非阻塞模型和多线程模型。单线程非阻塞模型的好处在于代码逻辑清晰不存在多线程资源竞争问题调试起来特别方便。对于投屏场景来说一般家里同时只有一台手机在投并发连接压力其实很小。所谓“多用户同时投屏”在客厅场景下几乎不存在就算有也往往是交替投屏而不是同时投屏。但如果只考虑单路流也得分清工作重心——虽然连接数少但video数据的吞吐量很高。4K30fps的H.265码流码率大约在15~20Mbps也就是说每秒钟要处理2MB左右的数据。这个量级在单线程模型里处理起来不至于吃紧但一旦加上了解码和渲染单线程就力不从心了。所以我的最后方案是混合型网络收发线程管收发丢到一个无锁队列里独立解码线程从队列里拿数据做解码渲染线程只管刷新显示。三个线程各管一段中间队列做缓冲。这个结构虽然不是最高性能的方案但绝对是最容易读懂、最方便维护的。如果你拿到的源码是纯单线程结构也别急着否定先看它是否有自带的缓冲区和丢帧策略。如果什么都没有那么在90%以上的使用场景里它一定会出现在投屏10分钟后画面越来越卡的问题。这个后面我会展开说。2. 核心协议与关键技术点拆解2.1 设备发现机制手机是怎么找到电视的无线投屏的第一步是设备发现。目前主流的方案有两种DLNA的SSDP简单服务发现协议和厂商自定义的局域网广播协议。我的server端两种都支持但代码侧还是更偏向后者因为可控性强调试起来不依赖第三方库。SSDP基于UDP固定往239.255.255.250:1900这个组播地址发NOTIFY报文。server端开机后每隔一定时间就主动广播一条“我还活着”的消息消息体是XML格式里面带设备类型、设备名称、UUID、服务描述地址等信息。手机端收到之后会在UI上列出一个可投屏设备列表。如果你需要在源码里实现SSDP有几个关键点需要注意组播要设置TTL跳数通常设置为1就够了避免跨路由广播造成网络风暴。必须监听1900端口且socket要设置SO_REUSEADDR否则多个服务进程会冲突。NOTIFY报文默认生存期Cache-Control建议设1800秒太短会导致手机频繁刷新设备列表太长会导致电视关机很久手机还认为它在。除了主动广播server端也要能被动响应手机端的“搜索请求”M-Search。收到M-Search之后需要在1秒内回复200 OK和对应的设备描述信息。很多手机App的搜索超时就卡在1秒这个阈值上回复慢了设备就“消失”了。这个细节实测非常关键。2.2 会话建立与媒体协商信令往返的潜规则发现设备之后手机端会向server端发一个“连接”或者“播放”请求通常是一个包含能力协商参数的JSON。比如手机端支持哪些编码格式H.264/H.265/VP9、支持的分辨率档位、帧率、码率范围、音频编码方式AAC/Opus。server端拿到这个清单后需要从中选出自己最擅长处理的一种组合——这里不是选最高级的而是选自己解码最稳的。在实际代码里这一步会遇到几个经典坑第一个坑H.265优先级问题。手机端默认会优先推H.265因为同等画质下码率更低省电。但很多电视盒子或者老电视的硬件解码器只支持H.265的Main Profile不支持Main1010bit色深。如果server端不检查解码器能力盲目接受手机端的高规格参数就会出现花屏或者黑屏但系统日志没有任何报错。所以源码里一定要加一个profile的检查最好还带一层软件解码兜底。第二个坑端口分配冲突。媒体流的传输端口不能写死建议每次会话都动态分配一个可用的端口。有源码喜欢固定用8000端口一旦和系统其他服务冲突投屏就失败还很难排查。动态分配的方法很简单先bind端口0再用getsockname拿到实际分配的端口号把这个端口号通过信令返回给手机端。第三个坑信令时序。部分手机端在发完连接请求后会立刻开始推流根本没有等待server端确认。所以server端不能严格按照“握手完成再收数据”的逻辑处理应该在信令处理的同时就提前把媒体接收模块准备好等数据一到就能立刻接收。否则开局就丢包画面出来就是花的。2.3 音视频数据传输与渲染码流怎么变成画面媒体数据的接收在投屏场景下基本都是基于RTP或者自定义的分包协议。这里有个要命的地方不管是RTP还是私有协议网络层拿到的都是一个个最大不超过1400字节的UDP包而一个H.264的关键帧I帧可能占用几十上百KB甚至接近1MB。所以payload需要片区组装按时间戳重组帧。顺序处理是这样的从socket收包按包序号检查是否乱序。如果是RTP解析RTP头取出sequence number和timestamp。将同一个timestamp下的所有分包按offset拼接成完整的一帧。将完整的一帧交给解码器硬解或软解。做这一步时需要重点处理一个参数GOP长度。GOP是两组关键帧之间的间隔一般情况下编码器会把GOP设置为2~4秒。也就是说每2到4秒才会出现一个I帧其余全是P帧。P帧解码强依赖前面的帧如果中间丢包导致P帧缺了参考帧画面就会花掉。比较巧妙的做法是server端在检测到丢包且无法恢复时主动向手机端发送一个“请求关键帧”的信令让对方立刻推一个I帧过来重置解码器状态。渲染这块如果你用FFmpeg做解码那么拿到的是AVFrame原始数据。如果走SDL2显示就给它喂AVFrame转成的纹理数据如果走DRM/KMS直通那就得做色彩格式转换成NV12或者RGB。尽量优先使用硬解。实测下来树莓派4B上用它的VideoCore GPU做H.264硬解4K 30fps的CPU占用率只有不到10%而软解则需要60%以上两者完全不是一个量级。3. 服务端源码结构分析与实操环境搭建3.1 源码目录设计与模块职责这是我个人项目里最终采用的目录结构也推荐你按这个思路去阅读或组织源码flyscreen_server/ ├── CMakeLists.txt # 构建脚本依赖FFmpeg、SDL2 ├── src/ │ ├── main.cpp # 入口初始化网络、解码、渲染线程 │ ├── network/ │ │ ├── udp_server.cpp # 媒体流UDP接收与拆包 │ │ ├── tcp_server.cpp # 信令TCP服务与JSON解析 │ │ └── ssdp.cpp # 设备发现广播与应答 │ ├── codec/ │ │ ├── decoder.cpp # FFmpeg解码封装硬解优先 │ │ └── ring_buffer.cpp # 音视频数据缓冲队列 │ ├── render/ │ │ ├── sdl_render.cpp # SDL2渲染线程 │ │ └── texture_cache.cpp │ └── common/ │ ├── logger.cpp # 日志模块 │ └── config.cpp # 参数配置读取 └── config.json # 端口、缓冲大小等配置main.cpp是整个server端的中枢做三件事读取配置文件、启动信令服务、创建解码与渲染线程。如果代码打开的顺序有问题后续排查会很痛苦。强烈建议在main.cpp里加一个状态机的日志输出把每一步初始化成功与否都打出来方便后期远程调试。3.2 环境依赖与编译配置要点编译这份源码需要提前安装这些依赖库libavcodec-dev / libavformat-dev / libavutil-devFFmpeg核心负责解码和格式解析。libsdl2-dev用于画面渲染窗口。libjsoncpp-dev信令的解析和生成。libssl-dev部分投屏协议的握手加密需要。CMakeLists.txt里的核心配置我给出一个可以直接用的版本cmake_minimum_required(VERSION 3.16) project(flyscreen_server) set(CMAKE_CXX_STANDARD 17) find_package(PkgConfig REQUIRED) pkg_check_modules(FFMPEG REQUIRED IMPORTED_TARGET libavcodec libavformat libavutil) pkg_check_modules(SDL2 REQUIRED IMPORTED_TARGET sdl2) pkg_check_modules(JSONCPP REQUIRED IMPORTED_TARGET jsoncpp) add_executable(flyscreen_server src/main.cpp src/network/udp_server.cpp src/network/tcp_server.cpp src/network/ssdp.cpp src/codec/decoder.cpp src/codec/ring_buffer.cpp src/render/sdl_render.cpp src/common/logger.cpp src/common/config.cpp ) target_link_libraries(flyscreen_server PkgConfig::FFMPEG PkgConfig::SDL2 PkgConfig::JSONCPP pthread )编译之前有一步值得做提前确认目标平台是否支持硬件解码。如果你的目标机器是树莓派需要开启enable-rpi相关编译选项如果是RK3568盒子需要在FFmpeg编译时打开--enable-rkmpp。这一步决定了“能跑”和“跑得流畅”的差别。如果编译时遇到找不到库的问题大概率是FFmpeg的库版本路径不对。执行pkg-config --libs libavcodec看一下输出如果输出为空说明开发包没安装完整而不是主库没装。这个问题在以前我帮人排查时反复出现过。3.3 运行效果与验证方法编译完成后在命令行启动server端./flyscreen_server -c config.json启动日志应该能看到下面的关键信息[INFO] SSDP service started, advertising on 239.255.255.250:1900 [INFO] TCP signaling server listening on 0.0.0.0:8642 [INFO] UDP media server listening on 0.0.0.0:8644 [INFO] Decoder initialized (HW accel: enabled) [INFO] Renderer initialized, 1920x1080 window created接着用手机App扫描设备观察TCP端口是否有收到消息以及UDP是否开始有数据流入。如果以上都是通的那这条链路就已经走通了。下面这一段是跑通之后性能验证的方法可以把手机端设置为4K分辨率投屏一部电影30分钟观察是否卡顿、音画是否同步顺便用top命令看CPU占用。正常情况下硬解投1080P的CPU占用应低于15%如果你看到CPU占用100%那大概率是解码走的是软解。4. 常见问题与排查技巧实录4.1 画面卡顿掉帧严重——缓冲策略没做对这是最常见、也是最影响体验的问题。症状是投屏刚开始很流畅大约1分钟后开始卡顿而且越卡越厉害还伴随着音画不同步。排查过程其实不复杂。先看日志里是否大量打印frame dropped意思是解码出来的帧来不及渲染被丢了。根本原因是缓冲区满。而且“满”的状态分两种——接收缓冲区满和解码缓冲区满。如果是接收缓冲区满了大概率是你的处理速度跟不上网络收包速度需要在解码线程里做优化检查解码日志里是不是每次avcodec_send_packet都返回EAGAIN是的话说明解码器内部队列饱和需要等待它把帧输出后再继续送数据。如果是解码缓冲区满那问题是解码速度跟不上码率。处理逻辑应该是动态丢包策略优先丢非关键帧保留关键帧。也就是说当检测到处理器跟不上时主动跳过连续的P帧只保留I帧牺牲一点流畅性保住画面不花不糊。我在源码里的实现逻辑是给buffered_packets设置一个水位线比如500个包。 一旦超过水位线开始按帧类型做抽样丢弃每4帧保留1帧P帧 如果超过800个包则只保留I帧P帧全丢。 这个策略实测非常有效能保证CPU占用在高负载时依然保持画面可看。4.2 手机App扫描不到server端——SSDP组播被防火墙拦截一台新的Linux设备上默认防火墙很可能拦截了UDP组播和入站的数据包。检查思路有两步第一步确认SSDP报文有没有发出来。在server端上用tcpdump抓包tcpdump -i eth0 udp port 1900 -vv如果能看到持续发出去的NOTIFY报文说明发送正常。问题多半在接收侧或防火墙。第二步确认防火墙有没有拦截入站UDP和TCP。如果你用的是UFW执行sudo ufw allow 1900/udp sudo ufw allow 8642/tcp sudo ufw allow 8644/udp另外还有一种情况手机和电视虽然连的是同一个路由器但开启了“AP隔离”也叫客户端隔离导致设备之间不能互相访问。这个在路由器设置里关掉“无线隔离”即可和代码无关但排查顺序上值得优先排除。4.3 画面花屏、绿屏——解码器能力协商没做好花屏的根本原因是接收到的码流和被初始化解码器参数不一致。最常见的不一致是分辨率变化。手机端在投屏过程中可能因为旋转屏幕实时切换了视频分辨率和旋转角度。如果server端没有相应做一个解码器reconfigure操作解码器就会拿着旧参数解新数据出来的自然就是花的。解决这个问题的标准做法是在解析RTP包时检查每个包里的resolution或者sps/pps信息是否和上一个包一致如果变了就重新初始化解码器。很多源码为了省事只在启动时初始化一次解码器这在你旋转屏幕的时候必翻车。Color space色彩空间不匹配也会导致绿屏。FFmpeg解码出来的AVFrame需要正确设置pixel format。如果你的屏幕输出配置了RGB但解码器输出NV12就需要做一次转换。这一步很隐蔽很多新手会忽略。我在源码里默认使用YUV420P作为内部流转格式到SDL渲染再统一转RGB能避开绝大多数兼容性问题。4.4 投屏中断、设备丢失——TCP心跳保活没过期无线投屏最怕用着用着突然断了。信令通道虽然只是一个TCP连接但它同样需要心跳保活。Android/iOS端发送投屏请求之后如果心跳包的空闲超过一定时间系统的TCP栈就会认为连接已死主动断开。这时候server端如果没有处理断开事件手机端也不知道服务端的状态就出现了“电视还在黑屏等下一帧手机觉得已经投屏结束”的诡异状态。处理方式是在server端做对称心跳每5秒检查一次上一次收到手机端数据包的时间如果超过10秒没有收到任何数据则认为这路投屏会话已死。紧接着需要做两件事——向手机端发送一个“结束会话”的信令以及清理掉本地的解码器实例和缓冲区。如果不做清理下一次投屏时解码器的内部状态还是上一路的大概率会在第一秒就崩掉或者花屏。5. 多屏联动与多人同屏的扩展思考Project源里目前跑的是单路投屏方案。如果你要扩展成多人轮播或者多屏拼接架构上可以这样思考。多屏联动两台server端同时显示同一画面最简单的实现是把数据源复制分发。一台主server端负责和手机通信然后通过UDP组播把收到的码流转发给其他server端其他server端只做解码和渲染。这种模式适合教育机构、展会等场景。注意分发和投屏走不同的网段或者端口避免互相干扰。多人同屏多台手机轮流投同一块大屏则需要引入调度器模块。调度器负责维护一个“当前投屏者”的状态新手机请求投屏时先排队等当前投屏者退出后再接上。这里还必须处理一个争端如果两台手机同时在投到底谁优先。通常采用FCFS先来先服务策略加一个“抢占开关”在配置里可选项属于产品策略层面的考量。我在这方面的个人项目实践体会是扩展的能力在刚开始架构时就要留好口子 比如会话管理不要写死在网络模块里抽出一个独立的session_manager类。 不然等你想支持双人投屏时会发现每个文件都在改改完又冒出一堆新bug。6. 源码阅读顺序建议与资源分享如果你是刚拿到项目源码不知道怎么读我给你一个“从外到内”的阅读顺序建议先读config.json明白有哪些参数可以调。读network/udp_server.cpp知道数据是怎么接进来的。读codec/decoder.cpp知道数据是怎么变出图像的。读render/sdl_render.cpp知道图像是怎么显示出来的。最后读main.cpp把所有模块串起来理解。只要按这个顺序过一遍源码你就能建立完整的链路认知。相反如果一上来就啃main.cpp很容易被大量线程初始化代码绕晕反而搞不清主次。顺带提一嘴我选择C而不是Python主要是因为解码和渲染的性能要求以及需要跟底层硬件解码接口打交道。如果你想用Python快速做个原型验证可以用ffmpeg-python加OpenCV把链路跑通但生产环境就别想了解码延迟和CPU占用都扛不住。网上有很多免费python源码我也见过有人用Python硬写了server端能出声能出画面但仅限720P低码率。一旦上了1080P帧率瞬间掉到个位数。至于编译和运行我建议先在x86的Linux虚拟机上跑通代码再用交叉编译工具打包到ARM盒子上。这样能把“音视频链路问题”和“交叉编译问题”分开排查效率最高。直接拿树莓派做开发调试会在环境配置上浪费大量时间。最后再分享一个小技巧在调试SSDP和信令阶段可以用netcat直接模拟手机端给server端发UDP包和TCP包而不需要真机配合。比如把一份准备好的JSON信令通过echo管道发给TCP端口echo {cmd:play,url:udp://0.0.0.0:8644,codec:h264} | nc -w 1 127.0.0.1 8642server端日志打印出收到这次请求就说明基本链路已经通了一半。剩下的就是反复插拔设备、旋转屏幕、切换网络把这些真实场景都过一遍源码才算真正吃透了。本文还有配套的精品资源点击获取 飞屏投影Server端源码解析：从设备发现到音画同步的完整实现
简介基于VNC实现的Android局域网飞屏投影server端源码面向Android开发、无线投屏应用学习者解决在无外网环境下通过自建服务实现手机屏幕投影到其他设备的问题。资源包为rar压缩格式大小约217KB共119个文件包含84个java源文件、24个xml配置文件、5个png图标、2个jar库以及工程与配置文件等其中java文件覆盖VNC连接、RFB协议解析、屏幕捕获等核心逻辑xml文件用于界面与交互配置。server端启用互动功能后会以自身IP为名称向局域网广播client设备开启互动即可发现服务端并显示IP用户摇晃手机或点击服务端名称即可完成互联投屏整体交互设计清晰。已有395人学习下载。通过该源码可完整掌握基于VNC的局域网投屏方案理解设备发现、连接握手到屏幕数据转发链路既能作为Android网络编程的实战范本也能在此基础上二次开发桌面控制、多屏互动等扩展功能适合希望深入VNC协议与P2P连接技术的开发者参考。 相信不少做影音集成、智能家居或者电视盒子开发的朋友都遇到过这种需求想把手机上的视频、照片或者电脑里的PPT一键甩到客厅大屏上但偏偏不想经过任何第三方云服务器也不想非得打开某个特定App才能投。这时候一个自建的“飞屏投影server端”就成了最顺手的东西。它本质上是一个跑在电视、盒子或树莓派上的服务进程负责接收手机端主动推过来的媒体流解码后交给显示层输出。这篇东西我会从server端源码的角度出发把整个投屏链路拆开来讲从设备发现、会话建立、码流传输到音画同步再到我实际搭建时踩过的坑一并整理出来。先说结论别看“飞屏”两个字听着玄乎server端代码的核心工作其实就三件事——被手机找到、把码流接住、把画面播出来。真正的复杂度集中在协议细节和异常处理上。我这份源码基于Linux环境开发用C编写服务主体音视频处理走FFmpeg网络层直接操作socket交互信令走JSON。如果你正准备做同类项目或者刚拿到一份投屏server端源码正愁不知道怎么下手照着下面的思路去读代码效率会高很多。1. 项目概述与整体设计思路1.1 飞屏投影server端到底在解决什么问题先把使用场景画清楚。一个典型的飞屏过程是这样的手机和电视处于同一个局域网内手机App通过某种协议发现电视上的server端服务然后发送一个投影请求。server端同意之后手机开始源源不断地把H.264或H.265编码的视频流推到电视端。电视端收到数据后做解码、渲染最终在屏幕上出画面。所以server端源码不是某一个单一功能文件而是一整套链路。它至少包含网络服务模块监听端口处理TCP/UDP连接。协议解析模块识别手机端发来的信令回复对应的握手应答。流媒体接收模块把收到的音视频数据包按顺序组装、去重、丢包重传。解码与渲染模块调用硬件或软件解码器把压缩后的视频帧变成能在屏幕上显示的图像。会话管理模块负责处理“谁在投”“投什么”“投多久”以及异常断开后的资源回收。这五个模块缺一不可。我见过不少半成品源码网络模块写得很扎实但解码和渲染是空的只打印日志不出画面这就是典型的“只知其一不知其二”。真正能跑的server端源码必须把这条路全部走通才算是一个完整的产品。1.2 架构选型为什么这样设计在设计server端时我经过了一段纠结期主要在两种架构之间做选择单线程非阻塞模型和多线程模型。单线程非阻塞模型的好处在于代码逻辑清晰不存在多线程资源竞争问题调试起来特别方便。对于投屏场景来说一般家里同时只有一台手机在投并发连接压力其实很小。所谓“多用户同时投屏”在客厅场景下几乎不存在就算有也往往是交替投屏而不是同时投屏。但如果只考虑单路流也得分清工作重心——虽然连接数少但video数据的吞吐量很高。4K30fps的H.265码流码率大约在15~20Mbps也就是说每秒钟要处理2MB左右的数据。这个量级在单线程模型里处理起来不至于吃紧但一旦加上了解码和渲染单线程就力不从心了。所以我的最后方案是混合型网络收发线程管收发丢到一个无锁队列里独立解码线程从队列里拿数据做解码渲染线程只管刷新显示。三个线程各管一段中间队列做缓冲。这个结构虽然不是最高性能的方案但绝对是最容易读懂、最方便维护的。如果你拿到的源码是纯单线程结构也别急着否定先看它是否有自带的缓冲区和丢帧策略。如果什么都没有那么在90%以上的使用场景里它一定会出现在投屏10分钟后画面越来越卡的问题。这个后面我会展开说。2. 核心协议与关键技术点拆解2.1 设备发现机制手机是怎么找到电视的无线投屏的第一步是设备发现。目前主流的方案有两种DLNA的SSDP简单服务发现协议和厂商自定义的局域网广播协议。我的server端两种都支持但代码侧还是更偏向后者因为可控性强调试起来不依赖第三方库。SSDP基于UDP固定往239.255.255.250:1900这个组播地址发NOTIFY报文。server端开机后每隔一定时间就主动广播一条“我还活着”的消息消息体是XML格式里面带设备类型、设备名称、UUID、服务描述地址等信息。手机端收到之后会在UI上列出一个可投屏设备列表。如果你需要在源码里实现SSDP有几个关键点需要注意组播要设置TTL跳数通常设置为1就够了避免跨路由广播造成网络风暴。必须监听1900端口且socket要设置SO_REUSEADDR否则多个服务进程会冲突。NOTIFY报文默认生存期Cache-Control建议设1800秒太短会导致手机频繁刷新设备列表太长会导致电视关机很久手机还认为它在。除了主动广播server端也要能被动响应手机端的“搜索请求”M-Search。收到M-Search之后需要在1秒内回复200 OK和对应的设备描述信息。很多手机App的搜索超时就卡在1秒这个阈值上回复慢了设备就“消失”了。这个细节实测非常关键。2.2 会话建立与媒体协商信令往返的潜规则发现设备之后手机端会向server端发一个“连接”或者“播放”请求通常是一个包含能力协商参数的JSON。比如手机端支持哪些编码格式H.264/H.265/VP9、支持的分辨率档位、帧率、码率范围、音频编码方式AAC/Opus。server端拿到这个清单后需要从中选出自己最擅长处理的一种组合——这里不是选最高级的而是选自己解码最稳的。在实际代码里这一步会遇到几个经典坑第一个坑H.265优先级问题。手机端默认会优先推H.265因为同等画质下码率更低省电。但很多电视盒子或者老电视的硬件解码器只支持H.265的Main Profile不支持Main1010bit色深。如果server端不检查解码器能力盲目接受手机端的高规格参数就会出现花屏或者黑屏但系统日志没有任何报错。所以源码里一定要加一个profile的检查最好还带一层软件解码兜底。第二个坑端口分配冲突。媒体流的传输端口不能写死建议每次会话都动态分配一个可用的端口。有源码喜欢固定用8000端口一旦和系统其他服务冲突投屏就失败还很难排查。动态分配的方法很简单先bind端口0再用getsockname拿到实际分配的端口号把这个端口号通过信令返回给手机端。第三个坑信令时序。部分手机端在发完连接请求后会立刻开始推流根本没有等待server端确认。所以server端不能严格按照“握手完成再收数据”的逻辑处理应该在信令处理的同时就提前把媒体接收模块准备好等数据一到就能立刻接收。否则开局就丢包画面出来就是花的。2.3 音视频数据传输与渲染码流怎么变成画面媒体数据的接收在投屏场景下基本都是基于RTP或者自定义的分包协议。这里有个要命的地方不管是RTP还是私有协议网络层拿到的都是一个个最大不超过1400字节的UDP包而一个H.264的关键帧I帧可能占用几十上百KB甚至接近1MB。所以payload需要片区组装按时间戳重组帧。顺序处理是这样的从socket收包按包序号检查是否乱序。如果是RTP解析RTP头取出sequence number和timestamp。将同一个timestamp下的所有分包按offset拼接成完整的一帧。将完整的一帧交给解码器硬解或软解。做这一步时需要重点处理一个参数GOP长度。GOP是两组关键帧之间的间隔一般情况下编码器会把GOP设置为2~4秒。也就是说每2到4秒才会出现一个I帧其余全是P帧。P帧解码强依赖前面的帧如果中间丢包导致P帧缺了参考帧画面就会花掉。比较巧妙的做法是server端在检测到丢包且无法恢复时主动向手机端发送一个“请求关键帧”的信令让对方立刻推一个I帧过来重置解码器状态。渲染这块如果你用FFmpeg做解码那么拿到的是AVFrame原始数据。如果走SDL2显示就给它喂AVFrame转成的纹理数据如果走DRM/KMS直通那就得做色彩格式转换成NV12或者RGB。尽量优先使用硬解。实测下来树莓派4B上用它的VideoCore GPU做H.264硬解4K 30fps的CPU占用率只有不到10%而软解则需要60%以上两者完全不是一个量级。3. 服务端源码结构分析与实操环境搭建3.1 源码目录设计与模块职责这是我个人项目里最终采用的目录结构也推荐你按这个思路去阅读或组织源码flyscreen_server/ ├── CMakeLists.txt # 构建脚本依赖FFmpeg、SDL2 ├── src/ │ ├── main.cpp # 入口初始化网络、解码、渲染线程 │ ├── network/ │ │ ├── udp_server.cpp # 媒体流UDP接收与拆包 │ │ ├── tcp_server.cpp # 信令TCP服务与JSON解析 │ │ └── ssdp.cpp # 设备发现广播与应答 │ ├── codec/ │ │ ├── decoder.cpp # FFmpeg解码封装硬解优先 │ │ └── ring_buffer.cpp # 音视频数据缓冲队列 │ ├── render/ │ │ ├── sdl_render.cpp # SDL2渲染线程 │ │ └── texture_cache.cpp │ └── common/ │ ├── logger.cpp # 日志模块 │ └── config.cpp # 参数配置读取 └── config.json # 端口、缓冲大小等配置main.cpp是整个server端的中枢做三件事读取配置文件、启动信令服务、创建解码与渲染线程。如果代码打开的顺序有问题后续排查会很痛苦。强烈建议在main.cpp里加一个状态机的日志输出把每一步初始化成功与否都打出来方便后期远程调试。3.2 环境依赖与编译配置要点编译这份源码需要提前安装这些依赖库libavcodec-dev / libavformat-dev / libavutil-devFFmpeg核心负责解码和格式解析。libsdl2-dev用于画面渲染窗口。libjsoncpp-dev信令的解析和生成。libssl-dev部分投屏协议的握手加密需要。CMakeLists.txt里的核心配置我给出一个可以直接用的版本cmake_minimum_required(VERSION 3.16) project(flyscreen_server) set(CMAKE_CXX_STANDARD 17) find_package(PkgConfig REQUIRED) pkg_check_modules(FFMPEG REQUIRED IMPORTED_TARGET libavcodec libavformat libavutil) pkg_check_modules(SDL2 REQUIRED IMPORTED_TARGET sdl2) pkg_check_modules(JSONCPP REQUIRED IMPORTED_TARGET jsoncpp) add_executable(flyscreen_server src/main.cpp src/network/udp_server.cpp src/network/tcp_server.cpp src/network/ssdp.cpp src/codec/decoder.cpp src/codec/ring_buffer.cpp src/render/sdl_render.cpp src/common/logger.cpp src/common/config.cpp ) target_link_libraries(flyscreen_server PkgConfig::FFMPEG PkgConfig::SDL2 PkgConfig::JSONCPP pthread )编译之前有一步值得做提前确认目标平台是否支持硬件解码。如果你的目标机器是树莓派需要开启enable-rpi相关编译选项如果是RK3568盒子需要在FFmpeg编译时打开--enable-rkmpp。这一步决定了“能跑”和“跑得流畅”的差别。如果编译时遇到找不到库的问题大概率是FFmpeg的库版本路径不对。执行pkg-config --libs libavcodec看一下输出如果输出为空说明开发包没安装完整而不是主库没装。这个问题在以前我帮人排查时反复出现过。3.3 运行效果与验证方法编译完成后在命令行启动server端./flyscreen_server -c config.json启动日志应该能看到下面的关键信息[INFO] SSDP service started, advertising on 239.255.255.250:1900 [INFO] TCP signaling server listening on 0.0.0.0:8642 [INFO] UDP media server listening on 0.0.0.0:8644 [INFO] Decoder initialized (HW accel: enabled) [INFO] Renderer initialized, 1920x1080 window created接着用手机App扫描设备观察TCP端口是否有收到消息以及UDP是否开始有数据流入。如果以上都是通的那这条链路就已经走通了。下面这一段是跑通之后性能验证的方法可以把手机端设置为4K分辨率投屏一部电影30分钟观察是否卡顿、音画是否同步顺便用top命令看CPU占用。正常情况下硬解投1080P的CPU占用应低于15%如果你看到CPU占用100%那大概率是解码走的是软解。4. 常见问题与排查技巧实录4.1 画面卡顿掉帧严重——缓冲策略没做对这是最常见、也是最影响体验的问题。症状是投屏刚开始很流畅大约1分钟后开始卡顿而且越卡越厉害还伴随着音画不同步。排查过程其实不复杂。先看日志里是否大量打印frame dropped意思是解码出来的帧来不及渲染被丢了。根本原因是缓冲区满。而且“满”的状态分两种——接收缓冲区满和解码缓冲区满。如果是接收缓冲区满了大概率是你的处理速度跟不上网络收包速度需要在解码线程里做优化检查解码日志里是不是每次avcodec_send_packet都返回EAGAIN是的话说明解码器内部队列饱和需要等待它把帧输出后再继续送数据。如果是解码缓冲区满那问题是解码速度跟不上码率。处理逻辑应该是动态丢包策略优先丢非关键帧保留关键帧。也就是说当检测到处理器跟不上时主动跳过连续的P帧只保留I帧牺牲一点流畅性保住画面不花不糊。我在源码里的实现逻辑是给buffered_packets设置一个水位线比如500个包。 一旦超过水位线开始按帧类型做抽样丢弃每4帧保留1帧P帧 如果超过800个包则只保留I帧P帧全丢。 这个策略实测非常有效能保证CPU占用在高负载时依然保持画面可看。4.2 手机App扫描不到server端——SSDP组播被防火墙拦截一台新的Linux设备上默认防火墙很可能拦截了UDP组播和入站的数据包。检查思路有两步第一步确认SSDP报文有没有发出来。在server端上用tcpdump抓包tcpdump -i eth0 udp port 1900 -vv如果能看到持续发出去的NOTIFY报文说明发送正常。问题多半在接收侧或防火墙。第二步确认防火墙有没有拦截入站UDP和TCP。如果你用的是UFW执行sudo ufw allow 1900/udp sudo ufw allow 8642/tcp sudo ufw allow 8644/udp另外还有一种情况手机和电视虽然连的是同一个路由器但开启了“AP隔离”也叫客户端隔离导致设备之间不能互相访问。这个在路由器设置里关掉“无线隔离”即可和代码无关但排查顺序上值得优先排除。4.3 画面花屏、绿屏——解码器能力协商没做好花屏的根本原因是接收到的码流和被初始化解码器参数不一致。最常见的不一致是分辨率变化。手机端在投屏过程中可能因为旋转屏幕实时切换了视频分辨率和旋转角度。如果server端没有相应做一个解码器reconfigure操作解码器就会拿着旧参数解新数据出来的自然就是花的。解决这个问题的标准做法是在解析RTP包时检查每个包里的resolution或者sps/pps信息是否和上一个包一致如果变了就重新初始化解码器。很多源码为了省事只在启动时初始化一次解码器这在你旋转屏幕的时候必翻车。Color space色彩空间不匹配也会导致绿屏。FFmpeg解码出来的AVFrame需要正确设置pixel format。如果你的屏幕输出配置了RGB但解码器输出NV12就需要做一次转换。这一步很隐蔽很多新手会忽略。我在源码里默认使用YUV420P作为内部流转格式到SDL渲染再统一转RGB能避开绝大多数兼容性问题。4.4 投屏中断、设备丢失——TCP心跳保活没过期无线投屏最怕用着用着突然断了。信令通道虽然只是一个TCP连接但它同样需要心跳保活。Android/iOS端发送投屏请求之后如果心跳包的空闲超过一定时间系统的TCP栈就会认为连接已死主动断开。这时候server端如果没有处理断开事件手机端也不知道服务端的状态就出现了“电视还在黑屏等下一帧手机觉得已经投屏结束”的诡异状态。处理方式是在server端做对称心跳每5秒检查一次上一次收到手机端数据包的时间如果超过10秒没有收到任何数据则认为这路投屏会话已死。紧接着需要做两件事——向手机端发送一个“结束会话”的信令以及清理掉本地的解码器实例和缓冲区。如果不做清理下一次投屏时解码器的内部状态还是上一路的大概率会在第一秒就崩掉或者花屏。5. 多屏联动与多人同屏的扩展思考Project源里目前跑的是单路投屏方案。如果你要扩展成多人轮播或者多屏拼接架构上可以这样思考。多屏联动两台server端同时显示同一画面最简单的实现是把数据源复制分发。一台主server端负责和手机通信然后通过UDP组播把收到的码流转发给其他server端其他server端只做解码和渲染。这种模式适合教育机构、展会等场景。注意分发和投屏走不同的网段或者端口避免互相干扰。多人同屏多台手机轮流投同一块大屏则需要引入调度器模块。调度器负责维护一个“当前投屏者”的状态新手机请求投屏时先排队等当前投屏者退出后再接上。这里还必须处理一个争端如果两台手机同时在投到底谁优先。通常采用FCFS先来先服务策略加一个“抢占开关”在配置里可选项属于产品策略层面的考量。我在这方面的个人项目实践体会是扩展的能力在刚开始架构时就要留好口子 比如会话管理不要写死在网络模块里抽出一个独立的session_manager类。 不然等你想支持双人投屏时会发现每个文件都在改改完又冒出一堆新bug。6. 源码阅读顺序建议与资源分享如果你是刚拿到项目源码不知道怎么读我给你一个“从外到内”的阅读顺序建议先读config.json明白有哪些参数可以调。读network/udp_server.cpp知道数据是怎么接进来的。读codec/decoder.cpp知道数据是怎么变出图像的。读render/sdl_render.cpp知道图像是怎么显示出来的。最后读main.cpp把所有模块串起来理解。只要按这个顺序过一遍源码你就能建立完整的链路认知。相反如果一上来就啃main.cpp很容易被大量线程初始化代码绕晕反而搞不清主次。顺带提一嘴我选择C而不是Python主要是因为解码和渲染的性能要求以及需要跟底层硬件解码接口打交道。如果你想用Python快速做个原型验证可以用ffmpeg-python加OpenCV把链路跑通但生产环境就别想了解码延迟和CPU占用都扛不住。网上有很多免费python源码我也见过有人用Python硬写了server端能出声能出画面但仅限720P低码率。一旦上了1080P帧率瞬间掉到个位数。至于编译和运行我建议先在x86的Linux虚拟机上跑通代码再用交叉编译工具打包到ARM盒子上。这样能把“音视频链路问题”和“交叉编译问题”分开排查效率最高。直接拿树莓派做开发调试会在环境配置上浪费大量时间。最后再分享一个小技巧在调试SSDP和信令阶段可以用netcat直接模拟手机端给server端发UDP包和TCP包而不需要真机配合。比如把一份准备好的JSON信令通过echo管道发给TCP端口echo {cmd:play,url:udp://0.0.0.0:8644,codec:h264} | nc -w 1 127.0.0.1 8642server端日志打印出收到这次请求就说明基本链路已经通了一半。剩下的就是反复插拔设备、旋转屏幕、切换网络把这些真实场景都过一遍源码才算真正吃透了。本文还有配套的精品资源点击获取