1.Miracast技术详解（四）：Sink源码解析
2.ZLMediaKit 服务器源码解读---RTSP推流拉流
3.解决FFmpeg播放RTSP推送的接p接H265码流报错问题
4.从零开始写一个RTSP服务器（五）RTP传输AAC

Miracast技术详解（四）：Sink源码解析

       Miracast Sink端源码最早出现在Android 4.2.2版本中，可通过android.googlesource.com查看。收源收然而，接p接在Android 4.3版本之后，收源收Google移除了这部分源码，接p接详细移除记录可在android.googlesource.com上查阅。收源收360没有审核源码尽管Sink端代码被移除，接p接但Source端源码依然存在。收源收通过使用Android手机的接p接投射功能，仍可实现Miracast投屏发送端的收源收功能。

       为了查看源码，接p接推荐使用Android Studio，收源收以便利用IDE的接p接代码提示和类/方法跳转功能。首先新建一个Native Project，收源收将libstagefright相关源码拷贝至cpp目录，接p接并导入必要的include头文件。在CMakeLists.txt中添加这部分源码后，同步环境，以此引用相关类与头文件，提升查看源码的滑动抢红包 源码效率。

       Sink端核心类主要包括：WifiDisplaySink.cpp、RTPSink.cpp、TunnelRenderer.cpp。通过分析可得知，初始化操作主要在wfd.cpp中的main()方法内完成，重点关注sink->start()方法启动WifiDisplaySink，进而使用ip和端口参数执行相关操作。

       RTSP通讯涉及关键步骤，包括创建RTSP TCP连接、处理连接状态与数据异步通知。当连接建立后，开始进行RTSP协商与会话建立，处理RTSP M1-M7指令。请求与响应流程需参考前面的RTSP协议分析文章，这里不详细展开。

       处理RTSP消息时，首先判断消息类型，是Request还是Response。对于Request，外卖app软件源码主要处理Source端M1请求，并响应M2确认。对于Source端M3请求，处理相关属性及能力，如RTP端口号、支持的音频和视频编解码格式等。M4与M5请求则分别进行常规的响应处理。

       在发送完Setup M6请求后，注册onReceiveSetupResponse()回调，用于完成RTSP最后一步，即发送PLAY M7请求。此时，Source端会按照Sink指定的UDP端口发送RTP数据包，包含音视频数据。

       RTSP协商与会话建立完成后，数据流通过RTPSink处理，建立UDP连接并解析RTP数据包。在TunnelRenderer中接收并播放音视频流。流程包括消息处理、滚动字幕的源码环境初始化、TS包解析、音视频裸流解码与播放等。

       源码解析过程中，关键步骤包括初始化RTPSink、建立UDP连接、处理RTP与RTCP数据、解析TS包并获取音视频裸流等。移植Native Sink端难点在于隔离与处理Native相关依赖，如异步消息机制、网络连接实现等。建议在应用层实现RTSP连接、音视频解码与渲染功能，然后移植底层解析代码，以减少依赖，提高移植效率。

ZLMediaKit 服务器源码解读---RTSP推流拉流

       RTSP推流与拉流在ZLMediaKit服务器源码中有着清晰的解析过程和处理逻辑。数据解析通过回调到达RtspSession类的onRecv函数，进而进行分包处理，.apk文件获取源码头部数据与内容分离。根据头部信息判断数据包类型，rtp包与rtsp包分别由onRtpPacket和onWholeRtspPacket函数处理。

       RTSP处理过程中，解析出的交互命令被分发至不同的处理函数。对于rtp包处理，数据封装成rtp包后，执行onBeforeRtpSorted函数进行排序，排序后的数据放入缓存map，最终回调到RtspSession的onRtpSorted函数。这里，回调数据进入RtspMediaSourceImp成员变量，该变量指向RtspDemuxer解复用器，用于H等视频格式的解复用。

       在H解复用器中，rtp包经过一系列处理后，由HRtpDecoder类的decodeRtp函数转化为H帧数据，最终通过RtpCodec::inputFrame函数分发至代理类。代理类在处理H帧数据时，分包并添加必要参数（如pps、sps信息），然后通过map对象将数据传递给多个接收者。

       处理完H帧后，数据将流转至编码阶段。在RtspMediaSourceImp中，H帧数据被传递至MultiMediaSourceMuxer编码类。在编码过程中，数据通过RtspMuxer的inputFrame接口进入编码器HRtpEncoder，最后被打包成rtp包，准备分发。

       总结而言，RTSP推流过程主要包含数据解析、视频解复用与编码三个关键步骤。在拉流阶段，通过鉴权成功后获取推流媒体源，利用play reader从缓存中取出rtp包并发送给客户端。

解决FFmpeg播放RTSP推送的H码流报错问题

       RTSP，实时流传输协议，常用于传输视频流。许多流媒体平台，如B站的ijkplayer，都是基于FFmpeg的FFplay内核。我曾分享过关于使用RTSP推送H码流的文章，包括本地拉流和编码时的推流显示。然而，当尝试使用FFplay处理RTSP推送的H码流时，遇到了报错"illegaltemporal ID in RTP/HEVC packet"。

       这个错误提示指向了H的NALU Header中的temporal ID问题。FFmpeg的源码检查了这个值，如果为0，会报错。H标准规定temporal ID不能为0，因此这个检查是合理的。问题可能出在RTP封装过程，而非原始码流，因为本地H码流的NALU Header值并不是0。

       为了解决这个问题，我深入研究了RTP封装H裸流的原理，发现在HSource.cpp的HandleFrame函数中，处理NALU数据时忽略了起始码。修正这一逻辑后，成功用FFplay播放了RTSP推送的H视频，尽管与VLC的播放效果相比稍有卡顿。FFplay播放的命令行参数包括指定窗口名称和分辨率。

       总结来说，通过问题定位和源码解析，我解决了FFplay在处理RTSP H码流时的报错，实现了本地H视频的正确播放。这个过程对理解FFmpeg工作原理和RTSP封装有帮助。

从零开始写一个RTSP服务器（五）RTP传输AAC

       本文目标：实现通过VLC播放SDP文件并听到AAC音频。

       1. RTP封装与发送

       虽然前面已介绍过，但为了回顾，这里再次提及。RTP数据包由头部和载荷组成，我们构建了一个结构体来代表RTP头部，并创建了发送包的函数。RTP头部的细节请参考之前关于RTSP协议的文章。

       下面是RTP包和发送函数的实现，其中使用htons函数来确保网络字节序（大端模式）的正确性：

       rtp.h 和 rtp.c 文件在此部分频繁使用。

       2. AAC RTP打包

       AAC音频以ADTS帧的形式存在，每个ADTS帧有特定的7字节头部，包含了帧大小信息。将AAC帧的头部和数据分开，仅保留AAC数据部分，每帧打包成一个RTP包。RTP载荷前四个字节有特殊含义，后面是AAC数据，大小在第三个和第四个字节中用位表示。

       3. AAC SDP媒体描述

       媒体描述的SDP格式包括"M="行，指定音频类型、端口、传输协议和负载类型。例如，`m=audio RTP/AVP `，表示音频流使用号负载类型（AAC）。详细SDP内容可参考RTSP协议讲解。

       4. 测试与操作

       将源代码（rtp.c、rtp.h 和 rtp_aac.c）与sdp文件(rtp_aac.sdp) 保存，使用test.aac作为音频源。编译并运行程序，确保运行时的IP地址与SDP中指定的目标地址一致，然后通过VLC加载SDP文件，即可听到音频。后续文章将介绍如何构建完整的AAC RTSP发送服务器。