如何用RtspClientSharp获取视频流信息？方案选择咨询

1. 关于RtspClientSharp的功能遗漏与代码修改 #

RtspClientSharp在建立RTSP连接时会解析SDP会话描述协议，里面包含编解码器、码率等核心流信息，但默认没有将这些信息暴露为公开API。你可以先做以下检查确认是否遗漏：

• 查看RtspClient实例的GetMediaStreams()返回的MediaStream对象，是否有隐藏的CodecInfo或SdpMediaDescription相关内部属性（可通过反射临时验证）；
• 检查库的最新版本，确认是否在后续更新中添加了媒体参数获取功能。

如果确认没有公开API，修改代码是可行方案：

• 在SdpParser解析SDP的逻辑中，提取m=行的编解码器信息、b=行的码率信息；
• 在MediaStream类中添加公开属性（比如CodecName、Bitrate），将解析后的信息存储并对外提供；
• 若需要RTSP协议交互中的额外参数（如SETUP响应中的带宽信息），可在RtspClient的请求处理逻辑中提取对应字段并封装。

2. FFmpeg+C+++PInvoke方案的优劣性 #

这个方案并非绝对更优，需结合你的场景判断：

优势 #

• FFmpeg对RTSP流的兼容性更强，能解析更多复杂流参数，支持的编解码器种类更全；
• 若后续有媒体转码、格式转换等需求，该方案可无缝扩展；
• 无需修改第三方库，避免维护fork版本的成本。

劣势 #

• 需要额外编写C代码封装FFmpeg的API，还要处理C#与C之间的PInvoke数据交互（如字符串、结构体传递），开发成本更高；
• 引入FFmpeg依赖后，部署时需携带对应的动态库，增加分发复杂度；
• 若你已基于RtspClientSharp完成帧接收的核心逻辑，跨语言调用会增加架构复杂度。

选择建议 #

• 如果只是补充获取流信息的功能，修改RtspClientSharp代码更直接，无需额外依赖，架构更简洁；
• 如果需要更全面的媒体处理能力，或对RTSP流的兼容性要求极高，FFmpeg方案更适合长期维护。

内容的提问来源于stack exchange，提问作者theateist