Stream corrupt error and then rtmpdump goes nuts

[Neill Mitchell]

Yes, I see exactly the same problems. I've upped the TCP buffers to 12MB 
and it's still unreliable. When you think about it, if the program can't 
keep up then it doesn't matter how big you make the low level TCP 
buffers, rtmpdump's own buffer will overflow. The TCP buffers are there 
to optimise the naturally bursty nature of normal data transfers. But 
these streams are a sustained download of hundreds of megs.

I think this is down to purely down to loop overhead processing speed. 
When rtmpdump has 1KB buffers it simply can't loop round fast enough to 
keep up with the data pouring in at 80MB/sec. With 4KB buffers the loop 
runs at a quarter of the frequency and it manages.

This is all conjecture of course, but the only way I'm managed to 
achieve reliability since upgrading to Infinity 2 is to either 
artificially throttle my connection, or up rtmpdump's buffers.

Cheers
Neill.
> Are you seeing exactly the same thing ("Wrong data size" error followed
> by bogus chunksize values), or just general rtmpdump misbehaviour?  This
> may not be relevant, but your initial report was missing most of the
> trace log, so we couldn't see what was happening as the connection was
> set up and the stream initiated.
>
> I think you would need a larger max receive buffer size to make a valid
> test.  From your earlier report, stock rtmpdump only worked reliably up
> to 30 Mbps with the default receive buffer settings.  That means with
> the throttle open you would need to buffer 50 Mbps, which is well north
> of 4 MB.  You're achieving roughly the same effect by increasing
> rtmpdump's internal buffer size by 4x.
>
> Of course, this pre-supposes that the garbage values fed to rtmpdump
> stem solely from data lost due buffer overflows.  It could just be that
> the Flash server is misbehaving or is not sufficiently robust, in which
> case no amount of tuning will make a difference.
>
>
>
>