发送安卓H264捕获了一个RTP流 [英] Send Android h264 capture over a rtp stream
问题描述
我正在写一个RTP视频流处理器为Android，从一个Android本地套接字读取H264 codeD数据，并打包了。问题是，我做到了，但我不断收到黑框在客户端（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的 - >星号 - > 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（第一，的第二）不同的读取输入缓冲液（按顺序）。如果我这样做是正确的前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
这是正确的？
is this correct?
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设备是华硕变形总理与Android ICS。
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.
我要送的分组模式（ 1 ）和用户级别-ID（<$ C C $> 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.
干杯。
推荐答案
1）没有的Android H264流格式。打包应遵循 RFC6184 如果RTP作为传输协议。启动code不RTP有效载荷格式present。什么是包含在RTP包，完全取决于打包方式，指定，如果NAL单元可被聚集，碎片化等阅读上的分组模式，获取更多信息。打包方式通过SDP通常沟通。
1) 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.
2）时间戳是RTP报头的一部分。 NAL单元的长度也取决于打包方式
2) Timestamp is part of RTP header. Length of a NAL unit again depends on packetization mode.
3）你是什么意思标记？你的意思是，RTP标志位设置？如果是这样，这又必须遵循RFC所设定的规则。
3) 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.
这篇关于发送安卓H264捕获了一个RTP流的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
