h264编码数据分包问题

[muyiyj]

我采用h264的编码，编码成一帧后，对其进行分包，然后利用jrtplib库对rtp包进行传输。
问题：由于h264编码后的一帧数据可能很大（后期运用于无线传输，无线传输中包最大字节数支持300，而一帧数据如I帧，可能有1500字节左右），所以，需要对编码后的帧进行分包。
请问高手，应该以什么样的规则进行分包呢？目前，我能想到的就是：1，按固定字节数如288字节分包；2，按编码后slice片来分包。不知道有没有什么更好的方法进行分包呢？
麻烦大家详细说明下分包过程。

[muyiyj]

自己顶一下，高手来帮忙解答下啊。

[soswaidao]

友情帮顶，友情帮顶

[muyiyj]

来人帮我解答下啊

[muyiyj]

自己顶下

[muyiyj]

难道都没人会么？

[red-fly]

按照300来分包，剩下不够300的部分，可以采取以下策略中的一个：
1. 直接按照剩下的数量打包发送
2. 在等待一定时间后，如果收到了接下来的数据，则连接后再按照300分包发送，如果等不到，则再把剩下的打包发送。这个策略可以在一定程度上减少发送次数，有利提高发送效率，减少实际的传输数据(网络底层协议)，但是它可能会导致最后一部分数据传不过去(数据不完整)，以及延迟

[zkaikai]

应该是按编码后slice片来分包，用的编码器不一样不知道它给你返回的数据是什么样的。 做得好的话，出来的时候就已经把各分片的NAL头打好了，不然可能得你自己加头。

[muyiyj]

[Quote=引用 6 楼 jszj 的回复:]
按照300来分包，剩下不够300的部分，可以采取以下策略中的一个：
1. 直接按照剩下的数量打包发送
2. 在等待一定时间后，如果收到了接下来的数据，则连接后再按照300分包发送，如果等不到，则再把剩下的打包发送。这个策略可以在一定程度上减少发送次数，有利提高发送效率，减少实际的传输数据(网络底层协议)，但是它可能会导致最后一部分数据传不过去(数据不完整)，以及延迟
[/Quote]
1，我查阅了些资料，还有Ti官网下的代码，基本都是按固定字节数分包，然后打在FU_A片中进行发送。
2，你说的第2点，确实可以提高效率，但存在一个问题，那就是你说的，如果一旦某部分数据收不到，就会导致解码解不出图像。目前一般解码方式是，收到完整的一帧数据包后，检查完整性和排序，如果丢包，直接丢掉这一帧。如果采用你第2点方式，会出问题。

[muyiyj]

[Quote=引用 7 楼 zkaikai 的回复:]
应该是按编码后slice片来分包，用的编码器不一样不知道它给你返回的数据是什么样的。 做得好的话，出来的时候就已经把各分片的NAL头打好了，不然可能得你自己加头。
[/Quote]
我考虑过，如果按slice方式来分，你怎么知道哪个位置是slice的末尾呢？(就是一个标志性字节，类似于起始码"00 00 00 01",我查了很久，都不知道如何来区分第1片slice和第2片slice之间分割点再哪儿)。

[zkaikai]

你看看开头一般是不是41？

[muyiyj]

[Quote=引用 10 楼 zkaikai 的回复:]
你看看开头一般是不是41？
[/Quote]
光一个字节能判断吗？一般都是几个字节组成的吧

[muyiyj]

自己顶下

[zkaikai]

我是从抓包分析出来的，抓包工具对它的解释是NAL头或者payload的第一个字节，再后面的字节涉及具体内容就找不出规律了

[D3DEB21]

对每一帧进行分包，最后一个包不足一个包容量，直接发送。
一帧发完，再发下一帧。

要定义一个可变长的数据结构作发送包的缓存。

我就是这样传h264图像数据

[muyiyj]

[Quote=引用 13 楼 zkaikai 的回复:]
我是从抓包分析出来的，抓包工具对它的解释是NAL头或者payload的第一个字节，再后面的字节涉及具体内容就找不出规律了
[/Quote]
我认为光靠一个字节来判断NAL不科学，很有可能编码后的视频数据会产生41字节。

[muyiyj]

我现在基本确定下来了，就采用固定字节长度来分包。
正如14楼说的：
对每一帧进行分包，最后一个包不足一个包容量，直接发送。
一帧发完，再发下一帧。