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.
_______________________________________________
get_iplayer mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/get_iplayer
