Stream corrupt error and then rtmpdump goes nuts

[Neill Mitchell]

Okay, I've played around with the TCP parameters on my Ubuntu 12.10 box.

I've uploaded a script to my dropbox account that tweaks a number of TCP 
parameters in Ubuntu. Most notably I've increased the receive buffer 
from 128K to 4MB. Obviously you can tweak this value to suit your 
available memory. The script needs to be run via sudo as the tweaks need 
root privileges.

http://dl.dropbox.com/u/32483061/set_buffer_size

I'm still testing, but it does seem to improve matters with the stock 
rtmpdump, so good idea dinkypumpkin!

Cheers
Neill.

On 08/01/13 17:00, get_iplayer-request at lists.infradead.org wrote:
>
> ------------------------------
>
> Message: 3
> Date: Tue, 08 Jan 2013 14:36:37 +0000
> From: dinkypumpkin <dinkypumpkin at gmail.com>
> To: get_iplayer at lists.infradead.org
> Subject: Re: Stream corrupt error and then rtmpdump goes nuts
> Message-ID: <50EC2EF5.1030703 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> There is already some flow control in rtmpdump in the sense that it uses
> the RTMP mechanism for negotiating bandwidth.  Still, that won't matter
> much when you receive garbage data, as appeared to be the case in your
> initial report. If there is garbage data in a RTMP message, it means
> that either the server send garbage, or some packets were lost, possibly
> as a result of socket buffer overflows.  You would hope that TCP flow
> control would prevent the latter, but there is no way to know what's
> going at the server end of the connection.  Still, I can't help but
> wonder if amending rtmdump is attacking the problem from the wrong end.
>    Perhaps it might be better to start with adjusting networking
> parameters on your system.  I looked at a vanilla Ubuntu 12.10 and found
> the max socket receive buffer size is 128KiB.  I wouldn't be at all
> surprised if that was too small for 30Mb+ connections.  If anyone with a
> fibre connection is bored enough to do some experimentation, it would be
> interesting to see if some TCP tuning could solve the problem.
>
>
>
>
> ------------------------------
>