Stream corrupt error and then rtmpdump goes nuts!

dinkypumpkin dinkypumpkin at gmail.com
Mon Dec 31 16:11:23 EST 2012


On 31/12/2012 14:45, Jon Davies wrote:
> On 31 December 2012 11:36, Neill Mitchell <neill at nlkmitchell.com> wrote:
> If you run get_iplayer with -v, it'll show you the rtmpdump command
> line.  Try running that again with a different buffer size (-b x,
> where x is in milliseconds - it defaults to 36000000), and that may
> help.  If it does there's probably a workaround (or fix?) that could
> be added to get_iplayer.

That's a different sort of buffering.  The -b parameter sets the max 
amount of data the client wants from the server in one go.  rtmpdump has 
a huge default (10 hrs), but it adjusts it to the duration of the file 
being streamed.  The effect is the same: rtmpdump is telling the server 
to send as much data as possible as fast as it can.  You might see some 
effect if you crank the -b value down to a very small number but I'm not 
sure that would solve the OP's problem since rtmpdump (unless running in 
realtime mode) will just ask for the next buffer's worth of data (via 
pause/unpause of stream) as soon as the previous buffer is received.

I think the OP is saying that his machine can't pull RTMP packets off 
the wire fast enough to process them.  At those connection speeds, I 
guess that seems plausible. The "RT" in RTMP stands for for "Real Time", 
after all.  rtmpdump is clearly getting garbage data when you see a 
message like this in the OP's initial report:

> DEBUG: HandleChangeChunkSize, received: chunk size change to 554422015

That value is nonsensical, so no surprise rtmpdump chokes.  Buffer 
overflow seems a likely culprit, since I don't think the server would 
send such an out-of-range value.  I'm not sure resizing the internal 
read buffer would be a reliable solution, though.  The stream still has 
be processed as a sequence of discrete messages, so if the network 
buffers can't be cleared fast enough, a larger internal buffer size 
might only delay the inevitable in those cases.

Perversely, I look forward to "suffering" from this problem should FTTC 
reach my area before the sun burns out.





More information about the get_iplayer mailing list