在 pcap 中使用多个音频视频会话进行 RTMP 解析

发布于 2024-11-19 02:07:48 字数 435 浏览 1 评论 0原文

我必须编写一个 RTMP 解析器,它将处理从wireshark 上的 RTMP 流捕获的数据包,并且我将从 pcap 中提取数据。

我已经阅读了规范,我能够理解握手过程,也能够定位 TCP 数据包中的媒体,但对于在单个 pcap 中交错的多个音频/视频会话的情况,我感到困惑,我们如何处理它在解析中,以使我们的解析器能够同时解析多个流。任何唯一性对于不同 RTMP 流的同时解析都会非常有帮助。

编辑(在 @Martin Redmond 的回答之后):是的,我能够弄清楚,但似乎一些 FLV 数据正在通过 RTMp 进行流式传输,但 FLV 标头丢失,并且似乎存在不同的握手,并且 FLV 数据正在流式传输相同的内容不同端口的IP。因此,我无法确定它是真正的 FLV 文件还是唯一的标头,就好像我只提取标头和其他数据一样,我无法从中制作 FLV 文件。

有什么方法可以验证或从该 RTMP 流中提取媒体???

I have to write a RTMP parser which will handle the packets captured form a RTMP stream on wireshark and i will extract the data from the pcap.

I have gone through the specs ad i am able to understand the handshake process and also able to locate the media in TCP packets but i am confused in case of Multiple Audio/Video session which are interleaved within a single pcap, how we can handle that in the parsing so as make our parser able to parse multiple stream simultaneously. Any uniqueness will be very helpful for the simultaneous parsing of the different RTMP streams.

EDIT (after @Martin Redmond's answer): yeah that I am able to figure out but it seems like some FLV data is being streamed over the RTMp but that FLV header is missing and there seems to be different handshake and FLV data is streaming for same IP with different ports. So, i am not able to find if its the real FLV file or only header as if i extract only the header and the other data, i am not able to make a FLV file from it.

Any way to validate or extract the media from that RTMP stream???

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

路还长,别太狂 2024-11-26 02:07:48

每个数据块的标头信息可让您确定该块属于哪个流。但这并不简单。标头信息被压缩,相关信息可能仅在流的开头发送,因此您需要为每个块提供上下文。

重要的部分是streamid。来自同一源的视频和音频将具有相同的streamid,但具有不同的通道号和数据类型。

在规格中。 Streamid 称为消息流 ID(第 6.1.2.1 节),并且仅与类型 0 标头一起发送。

The header information for each chunk of data lets you figure out which stream the chunk belongs to. It's not straight forward though. The header information gets compressed and the relevant info may have only been sent at the begining of the stream so you need have a context for each chunk.

The important part is the streamid. Video and audio from the same source will have the same streamid but will have different channel numbers and datatypes.

In the spec. the streamid is referred to as the message stream id (section 6.1.2.1) and is only sent with a type 0 header.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文