通过 rtp 流发送 Android h264 捕获 [英] Send Android h264 capture over a rtp stream
问题描述
我正在为 android 编写一个 rtp 视频流媒体，它从 Android 本地套接字读取 h264 编码数据并将其打包.问题是我做到了，但我一直在客户端(Voip)收到黑框.
I'm writing a rtp video streamer for android that reads h264 coded data from an Android local socket and packetize it. The thing is that I did it but I keep getting black frames in the client side (Voip).
通信是这样的:Android -> Asterisk -> Jitsi (Osx)(和反向)
The communication goes like this: Android -> Asterisk -> Jitsi (Osx) (and reverse)
有些事情我还没有理解:
There are a few things that I haven't understood yet:
1) Android 的 mediarecorder 给了我一个原始的 h264 流，我怎么知道基于该流的 NAL 何时开始/结束?它没有任何 0x000001 模式，但它有一个 0x0000(我假设它是一个分隔符)
1) Android's mediarecorder gives me a raw h264 stream, How can I know when a NAL starts / ends based on that stream? It doesn't have any 0x000001 pattern but it does have a 0x0000 (which I'm assuming is a separator)
添加更多信息.这些是 2(第一个，second)输入缓冲区的不同读取(按顺序).如果我猜对了，前 4 个字节应该用于获取 NALU 长度，第 5 个字节(索引 4)是 NALU 标头.
Adding more information. These are 2 (first, second) different reads of the input buffer (in order). If I got it right the first 4 bytes should be used to get the NALU length and the 5th one (index 4) is the NALU header.
我将在这里复制字节的值以备将来使用:
I'll copy here the byte's values for future usage:
1) 0 0 12 114 101 -72 4 25 -15 -1 -121 -53 .....
length = (114&0xFF) + (12&0xFF)*256 + (0&0xFF)
length -> 3186
forbidden = 101 & 0x80
forbidden -> 0
nri = 101 & 0x60
nri -> 96
nal_unit_type = 101 & 0x1F
nal_unit_type -> 5
2) 0 0 1 -93 97 -32 32 103 -14 93 -1 ....
length = (-93&0xFF) + (1&0xFF)*256 + (0&0xFF)
length -> 419
forbidden = 97 & 0x80
forbidden -> 0
nri = 97 & 0x60
nri -> 96
nal_unit_type = 97 & 0x1F
nal_unit_type -> 1
这是正确的吗?
2) 如何从该流中获取 NALu 时间戳及其长度?
2) How can I get the NALu timestamp and its length from that stream?
3) 出于某种原因，数据包被标记(即使我取消了标记).(如果您检查 pcap 文件)[已修复:我没有对每个数据包使用相同的 SSCR]
3) For some reason the packets are being marked (Even when I unset the marker). (In case you check the pcap file) [FIXED: I wasn't using the same SSCR for every packet]
这是来自星号的流的 pcap 捕获(它来自安卓).Android 设备是带有 Android ICS 的 Asus Transform Prime.
Here's a pcap capture of the stream coming from asterisk (wich comes from Android). The Android device is an Asus Transform Prime with Android ICS.
我在 sdp 中发送打包模式 (1) 和配置文件级别 ID (42801e)，我也尝试发送 sprops (sps: Z0KAHpWgUHxA, psp: aM48gA==) 参数但没有改变.
I'm sending the packetization-mode (1) and profile-level-id (42801e) in the sdp, I've also tried sending the sprops (sps: Z0KAHpWgUHxA, psp: aM48gA==) parameter but nothing changed.
干杯.
推荐答案
没有android h264 流格式".如果使用 RTP 作为传输协议，则打包应遵循 RFC6184.RTP 有效载荷格式不存在起始代码.RTP 数据包中包含的内容完全取决于指定 NAL 单元是否可以聚合、分段等的打包模式.阅读 打包模式 了解更多信息.打包模式通常通过 SDP 进行通信.
There is no "android h264 stream format". Packetization should follow RFC6184 if RTP is used as the transport protocol. The start code is not present of the RTP payload format. What is contained in an RTP packet, depends entirely on the packetization mode which specifies if NAL units may be aggregated, fragmented, etc. Read the RFC section on packetization modes for more info. Packetization mode is usually communicated via SDP.
时间戳是 RTP 标头的一部分.NAL 单元的长度再次取决于打包模式.
Timestamp is part of RTP header. Length of a NAL unit again depends on packetization mode.
标记是什么意思?您的意思是设置了 RTP 标记位吗?如果是这样，这又必须遵循 RFC 中规定的规则.
What do you mean by marked? Do you mean that the RTP marker bit is set? If so, this again must follow the rules laid out in the RFC.
这篇关于通过 rtp 流发送 Android h264 捕获的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
