I am streaming raw AAC RTP packets to wowza. I also have a custom player that expects each RAW AAC packet from wowza. It looks like wowza is optimizing packet sizes by combining several AAC packets together before streaming to the client. Is there a way to prevent this? If not does Wowza prepend an ADTS header to each AAC frame?
Does it work on standard players, e.g. Flash?
Richard
Yes, we do combine multiple into a single RTP packet. At this time there is not a way to control this. I will see if I can make this configurable in a future release.
Charlie
Yes, that is correct - RFC-3640 .
Charlie
The stream works fine on all players. I assume they are looking at the packet. My player is very simple. It assumes a single AAC frame in a single RTP AU. I did confirm I am sending a single AAC encoded frame per RTP/UDP packet (around 180 bytes). It really looks like Wowza combines 2 to 3 AAC frames. I send RTP packets with an AAC payload of 180 bytes on average. I get back payload sizes of 360 on average with the occasional payload size of 520+.
I was just wondering if Wowza combines incoming AAC frames into a single packet with multiple AU data sections, or possibly uses a container format such as ADTS.
Thanks Charlie. It’s not too big a deal. Just took me by surprise a little bit. It’s straight forward to parse the RTP packet.
Are you writing out AU headers for the AU data section? I am parsing the AU Headers Length just fine which shows, for example, that the total size is 48 for 3 AAC frames in a single packet. This is correct as sizelength=13 and indexlength and indexdeltalength is 3. However, the AU Size Length is not parsing out right. Maybe I am not understanding RFC-3640, but from what I understand the first 13 bits just after the AU Headers Length field would be the AU Size length in the first AU Header, followed by 3 bits for the index/indexdelta. I am assuming network byte order. This could be my problem.
Is Wowza using RFC-3640 when sending multiple access units of AAC data?
