| troller12 | 11-11-2017 05:25 PM |
Re: I will be happy to help
Hi guys,
today I did debug rtmpdump more in detail and found out the problem why it is not working with that stream and also how to fix this problem to force rtmpdump to work.
The problem is that the server send a close object information right after the first _result object and rtmpdump does handle it as close and does quit but the stream server does send after that go on and send the second _result object followed by next onStatus.No idea why the stream server does send this fake "close" back but maybe its really a simple trick to tell rtmpdump & Co here is nothing get guys. :) Normaly before close will send a _error object but not in this case so that the reason I did wonder to check out what it is.
Solution: We just need to handle that close answer from server of this stream.
Function: RTMP_ReadPacket or RTMP_ClientPacket.
In the returned AMF Body after calling that function you can check for the AMF type string (0x02) / AMF lenght 5 and the string name.
Debugger example after calling RTMP_ReadPacket
The easiest patch would be to change the close string to anything else.Only one letter needed like close to blose for example.Now in the RTMP_ClientPacket function it will check for the string lenght 5 what rtmpdump does handle as close but right there is also a string name check and if it does match = rtmpdump will stop to work go on and does close socket and finish.If the string was changed then it does bypass it and keeps reading the next packets and the stream runs and as result you get this to see.....
Nice or?So I cant compile a new rtmpdump version and just unpacked and patched rtmpdump file itself to check it out whether it works correctly.Maybe if someone can compile a new rtmpdump / librtmp with that patch (make it more advanced or add new extra command to bypass close AMF if server did send etc something like this you know).
greetz
today I did debug rtmpdump more in detail and found out the problem why it is not working with that stream and also how to fix this problem to force rtmpdump to work.
The problem is that the server send a close object information right after the first _result object and rtmpdump does handle it as close and does quit but the stream server does send after that go on and send the second _result object followed by next onStatus.No idea why the stream server does send this fake "close" back but maybe its really a simple trick to tell rtmpdump & Co here is nothing get guys. :) Normaly before close will send a _error object but not in this case so that the reason I did wonder to check out what it is.
Solution: We just need to handle that close answer from server of this stream.
Function: RTMP_ReadPacket or RTMP_ClientPacket.
In the returned AMF Body after calling that function you can check for the AMF type string (0x02) / AMF lenght 5 and the string name.
Code:
02 00 05 63 6c 6f 73 65 ...closeCode:
00408980=<rtmpdump.RTMP_ReadPacket>
Stack:
$ ==> > 0022BC88
$+4 > 0022B860 <---
$ ==> 0022B860 00011400
$+4 0022B864 00000003
$+8 0022B868 00000000
$+C 0022B86C 00000000
$+10 0022B870 00000012
$+14 0022B874 00000012
$+18 0022B878 00000000
$+1C 0022B87C 0032698A <----
0032698A 02 00 05 63 6C 6F 73 65 00 00 ...close..Nice or?So I cant compile a new rtmpdump version and just unpacked and patched rtmpdump file itself to check it out whether it works correctly.Maybe if someone can compile a new rtmpdump / librtmp with that patch (make it more advanced or add new extra command to bypass close AMF if server did send etc something like this you know).
greetz