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

[Kostya]

On Wed, Jul 29, 2009 at 07:37:22AM -0400, compn wrote:
> 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."

thanks for the info, I'll improve my code

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

no, since it does not support RTMPE (yet)
 
> -compn