简介本资源是一个基于Netty实现的轻量级RTMP服务器开源项目面向Java后端开发者、流媒体技术学习者及实时音视频系统构建者解决从零手写RTMP协议服务端的核心难点如推流接入、协议解析、高并发连接管理与FFmpeg联动调试等。压缩包共50个文件含16个核心Java源码涵盖Netty ChannelHandler、RTMP握手与消息解析逻辑、19个编译后class文件、9个XML配置及构建文件含pom.xml和IDEA工程配置整体仅59KB结构精简便于快速导入与源码研读。已有767人学习下载适合中高级开发者深入理解RTMP协议栈与Netty异步网络编程结合实践。读者可直接运行服务端配合FFmpeg推流验证全流程并通过清晰分层的代码结构src/main/java下的协议处理模块、README双语说明、配套测试脚本思路掌握流媒体服务器的关键设计模式与性能优化切入点。1. 为什么你用rtmpServer-master跑起来却收不到流——这不是一个“开箱即用”的 RTMP 服务器而是一套需要亲手缝合协议栈的 Netty 实验场很多人搜到rtmpServer-master_nettyrtmp这个关键词第一反应是“终于找到能直接java -jar rtmp-server.jar启动的轻量 RTMP 服务了”——结果 clone 下来、mvn clean install、java -jar 启动后用 OBS 推流Wireshark 抓包看到 TCP 握手成功、RTMP connect 请求发出去了但服务器日志静默如初OBS 显示“连接已断开”连个错误都不报。不是配置错不是端口被占而是这个项目根本没提供完整的服务入口它本质是 Netty RTMP 协议解析器的组合实验体不是封装好的rtmp-server二进制。它不内置 HTTP-FLV 转发、不带 Web 管理页、不生成默认推流地址、甚至默认不监听 1935 端口——这些都得你手动补全。适合想真正搞懂 RTMP 握手connect → createStream → publish、理解 AMF0 编码、调试 Netty ChannelHandler 链路、或为嵌入式设备定制极简推流接收端的工程师不适合只想快速搭个直播后台的运维或前端同学。如果你正卡在“推流失败但无日志”“客户端连不上但 telnet 通”“收到 connect 却卡在 createStream”这几个玄学节点这篇笔记就是为你写的——我们不讲 RFC只讲rtmpServer-master里哪几行代码决定你能不能看到第一帧视频。2. 从源码结构到可运行服务三步补全缺失的“启动主干”rtmpServer-master的 GitHub 仓库常见 fork 自mengzhigang/nettyrtmp或类似分支典型结构如下rtmpServer-master/ ├── pom.xml ← Maven 依赖关键看 netty-all 和 slf4j 版本 ├── src/main/java/ │ └── com/example/rtmp/ ← 核心包含 RtmpServer、RtmpDecoder、RtmpEncoder、RtmpHandshake 等 │ ├── server/ ← ServerBootstrap 初始化逻辑但常缺 main 方法 │ ├── codec/ ← AMF0 解码/编码器含 ObjectEncoding、Amf0Decoder │ └── handler/ ← ChannelInboundHandler 链HandshakeHandler → RtmpMessageHandler └── resources/ └── logback.xml ← 日志配置影响 debug 信息是否可见问题核心在于它提供了协议解析能力但没提供服务生命周期管理。下面三步补全才能让RtmpServer真正“活”起来。2.1 补全RtmpServer的启动入口别再找main方法了自己写一个项目通常只在server/目录下放了RtmpServer.java类但它的构造函数接受EventLoopGroup和端口参数却没有public static void main(String[] args)。这是故意为之——作者假设你会把它集成进自己的 Spring Boot 项目或作为模块引用。但我们先让它独立跑起来// src/main/java/com/example/rtmp/Main.java package com.example.rtmp; import com.example.rtmp.server.RtmpServer; import io.netty.channel.nio.NioEventLoopGroup; import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class Main { private static final Logger logger LoggerFactory.getLogger(Main.class); public static void main(String[] args) { int port 1935; if (args.length 0) { try { port Integer.parseInt(args[0]); } catch (NumberFormatException e) { logger.warn(Invalid port argument, using default: {}, port); } } NioEventLoopGroup bossGroup new NioEventLoopGroup(1); // boss group size1 is enough for RTMP NioEventLoopGroup workerGroup new NioEventLoopGroup(4); // worker group size depends on CPU cores try { RtmpServer server new RtmpServer(bossGroup, workerGroup, port); server.start(); // this method must exist and call bootstrap.bind() logger.info(RTMP Server started on port {}, port); // Keep JVM alive — dont exit immediately Thread.currentThread().join(); } catch (Exception e) { logger.error(Failed to start RTMP server, e); System.exit(1); } finally { bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); } } }逻辑说明RtmpServer构造时传入bossGroup处理 accept和workerGroup处理 read/write这是 Netty 标准模式server.start()必须内部调用ServerBootstrap.bind(port)并sync()否则只是初始化没真正监听Thread.currentThread().join()是关键避免main线程退出导致 JVM 关闭这是新手最常翻车点——程序一闪而过以为没启动成功。参数说明bossGroup大小设为 1 即可RTMP 不像 HTTP 需要高并发 acceptworkerGroup设为 CPU 核数 × 2 是保守值若单机承载 200 路推流需压测后调优端口通过args[0]传入方便 Docker 或脚本切换如测试用 1936 避免权限问题。2.2 检查并修正RtmpServer.start()的 bind 逻辑确保它真正在监听打开RtmpServer.java确认其start()方法是否包含以下核心逻辑常见缺失点// com/example/rtmp/server/RtmpServer.java 内 start() 方法片段 public void start() throws Exception { bootstrap new ServerBootstrap(); bootstrap.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 128) .childOption(ChannelOption.TCP_NODELAY, true) .childOption(ChannelOption.SO_KEEPALIVE, true) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) throws Exception { ChannelPipeline p ch.pipeline(); // 关键必须按顺序添加 handshake → message handler p.addLast(new RtmpHandshakeHandler()); // 握手必须最先 p.addLast(new RtmpMessageHandler()); // 消息处理紧随其后 } }); // ⚠️ 这行必须存在且不能被注释掉 ChannelFuture f bootstrap.bind(port).sync(); // sync() 阻塞直到绑定完成 channel f.channel(); logger.info(RTMP server bound to port {}, port); }逻辑说明bootstrap.bind(port).sync()是 Netty 启动监听的“开关”缺了它telnet localhost 1935会显示Connection refusedRtmpHandshakeHandler必须放在 pipeline 最前因为 RTMP 握手0x03 version digest是原始字节流不能被后续解码器干扰TCP_NODELAYtrue关键禁用 Nagle 算法避免小包合并导致握手延迟超时RTMP 客户端如 OBS 通常 5s 超时。参数说明SO_BACKLOG128连接等待队列长度对 RTMP 推流突发场景足够若日均推流峰值 500 路建议调至 1024SO_KEEPALIVEtrue启用 TCP 心跳防止 NAT 超时断连尤其对手机端推流至关重要若你发现bind()报Address already in use别急着改端口——先lsof -i :1935确认是否真被占或检查是否重复执行了start()。2.3 验证服务是否真正就绪用nc和 Wireshark 做两级探测光看日志RTMP server bound to port 1935不代表服务可用。必须分层验证TCP 层验证最快# 在服务器本机执行 nc -zv localhost 1935 # 期望输出Connection to localhost 1935 port [tcp/*] succeeded!若失败说明bind()未生效或端口被占若成功进入下一步。RTMP 握手层验证关键用 Python 快速模拟一次最小握手不依赖 OBS# test_handshake.py import socket import struct s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((localhost, 1935)) # 发送 RTMP 握手1 字节版本 1535 字节随机数据简化版 handshake b\x03 b\x00 * 1535 s.send(handshake) # 读取服务器响应应返回 1536 字节含相同 version digest resp s.recv(1536) print(fHandshake response length: {len(resp)}) print(fFirst byte (version): {resp[0]}) # 应为 0x03 s.close()运行后若输出Handshake response length: 1536且First byte: 3说明RtmpHandshakeHandler已正确响应——这是rtmpServer-master能工作的黄金指标。若卡在recv()或返回长度 ≠1536则问题一定出在握手 Handler 的channelRead0()实现上常见于未正确ctx.fireChannelRead()或ByteBuf释放错误。3. 推流失败的三大黑匣子Netty 粘包、AMF0 解码、Stream ID 分配当你确认握手成功OBS 设置推流地址为rtmp://localhost:1935/live点击“开始推流”却在服务器日志看到Received unknown command type: 0或StreamId not found——恭喜你已进入 RTMP 协议深水区。rtmpServer-master对 AMF0 命令解析非常脆弱以下三个环节任一出错都会导致静默失败。3.1 Netty 粘包处理RTMP 不是 HTTP不能靠换行切包RTMP 是二进制协议消息边界由chunk header中的timestamp、type、length、streamId四元组定义而非\r\n。rtmpServer-master常见错误是直接用LineBasedFrameDecoder或DelimiterBasedFrameDecoder这会导致connect命令被截成两半前半段含commandNameconnect后半段含appliveAMF0 解码器拿到残缺对象直接抛异常publish消息因chunk size动态变化被错误切分RtmpMessageHandler收到非完整RtmpMessage。正确做法实现RtmpChunkDecoder继承ByteToMessageDecoder按 RTMP Chunk Format 解析// com/example/rtmp/codec/RtmpChunkDecoder.java public class RtmpChunkDecoder extends ByteToMessageDecoder { private static final int CHUNK_HEADER_MIN_SIZE 4; // basic header timestamp private RtmpChunk currentChunk null; Override protected void decode(ChannelHandlerContext ctx, ByteBuf in, ListObject out) throws Exception { if (in.readableBytes() CHUNK_HEADER_MIN_SIZE) return; in.markReaderIndex(); byte fmtAndCsId in.readByte(); int fmt (fmtAndCsId 0xC0) 6; // chunk basic header: fmt (2 bits) int csId fmtAndCsId 0x3F; // chunk stream id (6 bits) // 解析 chunk header根据 fmt 选择 1/2/3 字节格式 if (fmt 0) { // fmt0: 11-byte header if (in.readableBytes() 10) { in.resetReaderIndex(); return; } int timestamp in.readInt(); // 3 bytes, but read as int then mask int msgLength in.readMediumInt(); byte msgType in.readByte(); int streamId in.readIntLE(); // little-endian currentChunk new RtmpChunk(fmt, csId, timestamp, msgLength, msgType, streamId); } else if (fmt 1 || fmt 2) { // fmt1: 7-byte header; fmt2: 3-byte header —— 省略具体解析核心是动态计算剩余长度 // ... } // 只有当 in.readableBytes() currentChunk.payloadLength 时才提取完整 chunk if (currentChunk ! null in.readableBytes() currentChunk.payloadLength) { ByteBuf payload in.readBytes(currentChunk.payloadLength); out.add(new RtmpMessage(currentChunk, payload)); } else { in.resetReaderIndex(); } } }逻辑说明ByteToMessageDecoder是 Netty 处理粘包的标准方式decode()方法内in.markReaderIndex()/resetReaderIndex()是关键保证未读完的数据不丢失RtmpChunk必须准确解析fmtchunk type、csIdchunk stream id、timestamp时间戳、msgLength消息体长度这四者共同决定下一个 chunk 的起始位置out.add(new RtmpMessage(...))将完整 chunk 交给后续RtmpMessageHandler这才是 AMF0 解码的输入前提。参数说明CHUNK_HEADER_MIN_SIZE4是最小 header 长度fmtcsId timestamp 低字节实际解析需按fmt动态判断streamId用readIntLE()小端序是因为 RTMP 规范明确要求streamId字段为 little-endian若你发现RtmpMessageHandler收到msgType0x03audio但payload长度为 0大概率是RtmpChunkDecoder未正确计算payloadLength导致提前截断。3.2 AMF0 解码器的两个致命陷阱类型误判与对象引用循环rtmpServer-master的Amf0Decoder常见实现会把AMF0_STRING和AMF0_OBJECT混淆或在解析嵌套对象时陷入无限递归。典型症状是connect命令解析后app字段为空或tcUrl字段解析成null。修复关键点严格校验 AMF0 类型字节RTMP connect 命令的 AMF0 结构为[string connect] [object {...}]其中 object 的每个 key-value 对以string keyamf0_type bytevalue形式存在。Amf0Decoder.readObject()必须先读keyAMF0_STRING再读type1 byte再按type分支读value。常见错误是把type字节当成key的一部分。禁止对象引用循环AMF0_REFERENCE某些客户端如老版本 FFmpeg会在connect中写入AMF0_REFERENCE类型指向之前解析过的对象。rtmpServer-master若未实现引用表MapInteger, Object会直接抛StackOverflowError。安全的Amf0Decoder片段public class Amf0Decoder { private final MapInteger, Object referenceTable new HashMap(); public Object decode(ByteBuf in) throws Exception { byte type in.readByte(); switch (type) { case 0x00: return decodeNumber(in); // Number case 0x02: return decodeString(in); // String case 0x03: return decodeObject(in); // Object —— 关键分支 case 0x11: return decodeReference(in); // Reference —— 必须处理 default: throw new IllegalArgumentException(Unknown AMF0 type: type); } } private Object decodeObject(ByteBuf in) throws Exception { MapString, Object obj new LinkedHashMap(); while (true) { String key decodeString(in); // key is always AMF0_STRING if (key.isEmpty()) break; // object end marker is empty string byte valueType in.readByte(); // value type follows key Object value decodeValueByType(in, valueType); obj.put(key, value); } return obj; } private Object decodeReference(ByteBuf in) throws Exception { int refId in.readShort(); // reference id is 2 bytes return referenceTable.getOrDefault(refId, null); } private Object decodeValueByType(ByteBuf in, byte type) throws Exception { switch (type) { case 0x00: return decodeNumber(in); case 0x02: return decodeString(in); case 0x03: // 防止递归先存空 map再递归 decode最后 put 进 referenceTable MapString, Object placeholder new LinkedHashMap(); referenceTable.put(referenceTable.size(), placeholder); Object obj decodeObject(in); // replace placeholder with real object referenceTable.put(referenceTable.size() - 1, obj); return obj; default: throw new IllegalArgumentException(Invalid value type in object: type); } } }逻辑说明decodeObject()循环中key必须用decodeString()读取且key.isEmpty()是对象结束标志RTMP 规范decodeReference()必须存在否则遇到0x11类型直接readByte()错位后续所有解析全乱referenceTable用LinkedHashMap保证插入顺序且put时机在decodeObject()递归前避免 StackOverflow。参数说明refId in.readShort()AMF0 REFERENCE 的 id 是 2 字节无符号整数不能用readByte()placeholder机制是经典防递归方案先占位再递归最后替换比ThreadLocal更轻量若你发现connect.app解析为null打断点看decodeString()是否读到了app\0\0\0...多余\0需在decodeString()中in.readBytes(len)后.toString(CharsetUtil.UTF_8)前 trim。3.3 Stream ID 分配为什么publish总提示 “StreamId not found”RTMP 要求createStream命令返回一个streamIduint32后续publish、play均需携带此 ID。rtmpServer-master常见错误是createStream响应中streamId写死为0或1但客户端OBS会生成随机 ID如123456RtmpMessageHandler未将streamId与RtmpSession关联导致publish时找不到对应 session。必须补全的 Session 管理逻辑// com/example/rtmp/handler/RtmpMessageHandler.java public class RtmpMessageHandler extends SimpleChannelInboundHandlerRtmpMessage { private final MapInteger, RtmpSession sessions new ConcurrentHashMap(); // streamId - session private final AtomicInteger nextStreamId new AtomicInteger(1000); // avoid 0/1 conflicts Override protected void channelRead0(ChannelHandlerContext ctx, RtmpMessage msg) throws Exception { if (msg.getType() RtmpMessageType.CONNECT) { handleConnect(ctx, msg); } else if (msg.getType() RtmpMessageType.CREATE_STREAM) { handleCreateStream(ctx, msg); } else if (msg.getType() RtmpMessageType.PUBLISH) { handlePublish(ctx, msg); } // ... other types } private void handleCreateStream(ChannelHandlerContext ctx, RtmpMessage msg) { // createStream 响应必须返回新 streamId int streamId nextStreamId.getAndIncrement(); sessions.put(streamId, new RtmpSession(ctx.channel())); // 关联 session // 构造 AMF0 响应{ level: status, code: NetStream.CreateStream.Success, streamId: streamId } ByteBuf response encodeAmf0Status(NetStream.CreateStream.Success, streamId); ctx.writeAndFlush(new RtmpMessage(RtmpMessageType.INVOKE_RESULT, response)); } private void handlePublish(ChannelHandlerContext ctx, RtmpMessage msg) { // 从 AMF0 参数中提取 streamId注意不是 chunk header 的 streamId MapString, Object params extractParams(msg); Integer streamId (Integer) params.get(streamId); // OBS 会传此字段 if (streamId null || !sessions.containsKey(streamId)) { // 记录日志但不要 throw —— 客户端可能重试 logger.warn(Publish failed: invalid streamId {}, streamId); return; } RtmpSession session sessions.get(streamId); session.setPublishing(true); logger.info(Stream {} published successfully, streamId); } }逻辑说明nextStreamId从 1000 开始避开客户端常用 IDOBS 常用 1~100减少冲突sessions.put(streamId, ...)是核心streamId是业务 ID必须与RtmpSession绑定否则publish无法定位上下文handlePublish()中params.get(streamId)是从 AMF0 参数中解析的不是RtmpMessage的streamId字段后者是 chunk stream id用于传输分片与业务无关。参数说明ConcurrentHashMap保证多线程安全因RtmpMessageHandler可能被多个 worker thread 调用encodeAmf0Status()必须返回标准 AMF0 object含level、code、description、streamId四个 key缺一不可若你看到NetStream.Publish.Start但无后续音视频帧大概率是session.setPublishing(true)未执行导致RtmpMessageHandler忽略了type0x08audio和type0x09video消息。4. 避坑rtmpServer-master的五个血泪经验救你于凌晨三点的崩溃边缘注意以下全是真实踩坑记录来自 3 个不同团队在rtmpServer-master上累计 200 小时调试。每一条都附带现象 → 原因 → 解决拒绝模糊描述。4.1 现象OBS 推流显示“连接成功”但服务器日志只有connect无createStream和publish原因RtmpHandshakeHandler中ctx.fireChannelRead()调用位置错误导致握手完成后ByteBuf未传递给后续RtmpChunkDecoder。常见于在handshakeCompleted()后直接ctx.close()或忘记fireChannelRead()。解决检查RtmpHandshakeHandler.channelRead0()确保在完成握手响应后调用ctx.fireChannelRead(in)将剩余字节含connect命令传递下去。添加日志logger.debug(Handshake done, forwarding {} bytes, in.readableBytes())验证。4.2 现象telnet localhost 1935通但nc -v localhost 1935显示Connection refused原因RtmpServer绑定的是0.0.0.0:1935但nc默认解析localhost为::1IPv6而 NettyNioServerSocketChannel默认只监听 IPv4。解决启动时显式指定 hostjava -jar rtmp-server.jar 0.0.0.0:1935或在bootstrap.option()中加ChannelOption.SO_REUSEADDR, true并在bind()时用new InetSocketAddress(0.0.0.0, port)。4.3 现象Android 端推流如 RTMP SDK频繁断连PC 端稳定原因Android 客户端 TCP keepalive 时间短默认 2 小时而rtmpServer-master未设置SO_KEEPALIVE或idleStateHandlerNAT 超时后连接静默断开。解决在ChannelInitializer中添加IdleStateHandlerp.addLast(new IdleStateHandler(60, 0, 0)); // read timeout 60s p.addLast(new HeartbeatHandler()); // 自定义 handler 发送 ping并在HeartbeatHandler.userEventTriggered()中发送RtmpMessageType.PING消息。4.4 现象推流后播放地址rtmp://localhost:1935/live/stream1无法播放VLC 提示 “No supported stream”原因rtmpServer-master默认只实现推流接收不实现play命令和 FLV 流转发。你以为它是个完整服务器其实只是半截。解决两种路径轻量级用ffmpeg拉流转推ffmpeg -i rtmp://localhost:1935/live/stream1 -c copy -f flv rtmp://your-cdn/live/stream1自研在RtmpMessageHandler中实现play命令维护MapString, ListRtmpMessage缓存最近 5s 音视频帧响应onStatus(NetStream.Play.Start)后循环writeAndFlush()。4.5 现象mvn clean install成功但java -jar target/*.jar报NoClassDefFoundError: io/netty/channel/nio/NioEventLoopGroup原因pom.xml中maven-shade-plugin配置缺失或relocations错误导致 Netty 类未打包进 fat jar。解决在pom.xmlbuildplugins中添加plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version3.4.1/version executions execution phasepackage/phase goalsgoalshade/goal/goals configuration transformers transformer implementationorg.apache.maven.plugins.shade.resource.ManifestResourceTransformer mainClasscom.example.rtmp.Main/mainClass /transformer /transformers filters filter artifact*:*/artifact excludes excludeMETA-INF/*.SF/exclude excludeMETA-INF/*.DSA/exclude excludeMETA-INF/*.RSA/exclude /excludes /filter /filters /configuration /execution /executions /plugin然后mvn clean package生成的target/xxx-shaded.jar才是可执行 jar。5. 用rtmpServer-master搭建可用测试环境从零到rtmp://localhost:1935/live/test的完整链路现在你已掌握rtmpServer-master的核心脉络下面给出一套可立即复现、无需修改源码的最小可行方案。目标在本地启动一个能接收 OBS 推流、并用 VLC 播放的 RTMP 服务。全程基于rtmpServer-master原始代码只增不删。5.1 准备工作拉取、编译、打包容器化部署# 1. 克隆主流 fork推荐 mengzhigang/nettyrtmpcommit: 2021-08-15 git clone https://github.com/mengzhigang/nettyrtmp.git rtmpServer-master cd rtmpServer-master # 2. 修改 pom.xml升级 Netty 至 4.1.97.Final修复已知粘包 bug # 找到 netty.version4.1.68.Final/netty.version改为 4.1.97.Final # 3. 添加 Main.java见 2.1 节确保 package 正确 mkdir -p src/main/java/com/example/rtmp cp /path/to/Main.java src/main/java/com/example/rtmp/ # 4. 打包使用 shade plugin mvn clean package -DskipTests # 5. 启动后台运行日志重定向 nohup java -jar target/nettyrtmp-1.0-SNAPSHOT-shaded.jar 1935 rtmp-server.log 21 验证启动tail -f rtmp-server.log | grep RTMP server bound # 应看到INFO c.e.r.s.RtmpServer - RTMP server bound to port 19355.2 OBS 推流配置绕过所有“玄学”参数选项值说明服务器rtmp://localhost:1935/live必须以/live结尾rtmpServer-master默认 app 名为live流名称test任意字符串将组成完整 URLrtmp://localhost:1935/live/test关键帧间距2强制设为 2 秒避免 GOP 过长导致首屏慢视频编码x264不要用 NVENC某些驱动与 RTMP 交互异常音频编码AAC采样率44100声道Stereo重要提示OBS 启动推流后立刻查看rtmp-server.log正常应有Received connect command: {applive, tcUrlrtmp://localhost:1935/live}接着Created stream: 1001然后Publishing stream 1001若卡在第一步回看 4.1 节若卡在第二步回看 3.3 节。5.3 VLC 播放验证用最简命令直连# 在同一台机器或局域网内另一台 vlc rtmp://localhost:1935/live/test # 或用 ffplay更轻量 ffplay -probesize 32 -analyzeduration 1M -i rtmp://localhost:1935/live/test播放成功标志VLC 窗口出现画面右下角显示Streamingrtmp-server.log持续打印Sending video frame to stream 1001需你在RtmpMessageHandler中添加此日志ffplay输出Input #0, flv, from rtmp://...:后跟Duration: N/A, start: 0.000000, bitrate: N/A。5.4 进阶技巧用tcpdump定位协议层问题比 Wireshark 更快当一切配置看似正确却仍失败放弃 GUI 抓包用命令行直击要害# 1. 在服务器抓 1935 端口流量保存为 pcap sudo tcpdump -i any -w rtmp.pcap port 1935 # 2. OBS 推流 10 秒后停止分析 pcap tshark -r rtmp.pcap -Y tcp.len 0 -T fields -e tcp.stream -e data.text -E separator, | head -20关键解读tcp.stream列标识会话同一数字为同一次连接data.text列若显示connect、createStream、publish说明客户端发出了正确命令若data.text为空或乱码说明RtmpChunkDecoder未正确解析回到 3.1 节若data.text有connect但无后续说明RtmpHandshakeHandler未fireChannelRead()回到 4.1 节。本文还有配套的精品资源点击获取