[FFmpeg-devel] [PATCH] RTMP client support for lavf

compn tempn
Wed Jul 29 13:37:22 CEST 2009


On Wed, 29 Jul 2009 09:28:59 +0300, Kostya wrote:
>On Tue, Jul 28, 2009 at 07:22:02AM -0400, compn wrote:
>> On Tue, 28 Jul 2009 09:27:11 +0300, Kostya wrote:
>> >+/** maximum possible number of different RTMP channels */
>> >+#define RTMP_CHANNELS 64
>> 
>> according to this patch for rtmpdump, max channels should be increased:
>> -      RTMPPacket m_vecChannelsIn[64];
>> -      RTMPPacket m_vecChannelsOut[64];
>> +//      RTMPPacket m_vecChannelsIn[64];
>> +//      RTMPPacket m_vecChannelsOut[64];
>> +      RTMPPacket m_vecChannelsIn[65600];
>> +      RTMPPacket m_vecChannelsOut[65600];
>> 
>> it fixed this rtmp stream for me.
>> i've heard the spec uses a similar number, possibly 65599.
>
>Unlike me you can read the spec (hint, hint). For me it seems to be
>just unreasonably high.

adobe = unreasonable, therefor it must be true.

googling "rtmp 65599" shows me the inside of the rtmp spec 1.0 (without
signing anything), that rtmp supports 65597 streams from id 3-65599.

according to this page (from same google search):
http://p2p-sip.blogspot.com/2009/06/problems-in-rtmp.html
"As an example of complexity: the chunk stream ID field in the first
specification was initially intended to be up to 63 but later extended
to 65599. For ID 2 to 63, the first byte stores the value in its most
significant 6 bits. For ID in the range 64-319 the second byte stores
the value minus 64, whereas the first 6 bits of first byte store 0. For
values between 64-65599, the second and third bytes store the value
using a complicated formula whereas the first six bits of the first
byte store 1."

did you test my rtmp sample url? was it channel 66? did it work with
your 63 limit?

-compn



More information about the ffmpeg-devel mailing list