Customized rtmpdump binaries with patch file

[KSV]

Originally Posted by RedPenguin

For some reason rtmpsuck has never worked with these streams (rtmpsuck claims it fails and video continues in browser) this is what it always does with 2011-07-11 and identical error with your latest compile.

http://pastebin.com/VkbqL0vQ

i mean the latest rtmpsrv log not older rtmpsuck one.

[RedPenguin]

It looks like newer rtmpsrv is giving a very similar error to older rtmpsuck.

http://pastebin.com/tWJEYA28

[KSV]

Originally Posted by RedPenguin

It looks like newer rtmpsrv is giving a very similar error to older rtmpsuck.

http://pastebin.com/tWJEYA28

i seem to have pinpointed the issue. the main issue was that countAMF and dumpAMF functions in rtmpsrv were not taking new array types into consideration hence generating wrong command line in case there was any extra parameters to connect object.

change following in rtmpsrv.c and try:
countAMF:

      len += 2;
      if (p->p_name.av_val)
	len += p->p_name.av_len + 1;
      if((p->p_type == AMF_ECMA_ARRAY) || (p->p_type == AMF_STRICT_ARRAY))
        p->p_type = AMF_OBJECT;
      switch(p->p_type)
	{
	case AMF_BOOLEAN:

dumpAMF:

      argv[ac].av_val = ptr;
      if (p->p_name.av_val)
	*ptr++ = 'N';
      if((p->p_type == AMF_ECMA_ARRAY) || (p->p_type == AMF_STRICT_ARRAY))
        p->p_type = AMF_OBJECT;
      *ptr++ = opt[p->p_type];
      *ptr++ = ':';
      if (p->p_name.av_val)

[RedPenguin]

That's completely gets rid of the invalid AMF data, but for some reason it still errors out on RTMPDump:

https://dl.dropboxusercontent.com/u/...tmpsrv-log.txt

The thing I always noticed between the older and newer RTMPSrvs I had was when 2011-07-11 was recording it always claimed the AMF Data was "-C 0:0 -C 0:1" such as I seen from your fix, but the original ones from this thread claim they got the strange chars I mentioned before.

[KSV]

Originally Posted by RedPenguin

but for some reason it still errors out on RTMPDump

That's not the problem with rtmpdump. rtmpdump tries to connect with their sever on detected port (1935) and server disconnects the connection. it's also the reason why rtmpsuck doesn't work on this site. after disconnection their flash client switches to another port (probably 80 or 443) which is not redirected to rtmpsrv or rtmpsuck by default (check RTMPDumpHelper options). try after changing the port from 1935 to 80 or 443. it's better to use wireshark in this case to know which protocol (RTMPT ?) and port is being used.

[RedPenguin]

Originally Posted by KSV

That's not the problem with rtmpdump. rtmpdump tries to connect with their sever on detected port (1935) and server disconnects the connection. it's also the reason why rtmpsuck doesn't work on this site. after disconnection their flash client switches to another port (probably 80 or 443) which is not redirected to rtmpsrv or rtmpsuck by default (check RTMPDumpHelper options). try after changing the port from 1935 to 80 or 443. it's better to use wireshark in this case to know which protocol (RTMPT ?) and port is being used.

A wireshark analysis just seems to show normal HTTP/HTTPS traffic then the minute the stream plays a flow of "RTMP" traffic with a ton of "Unknowns (0x0)" which I always seem to see with RTMPE on port 1935, which is confirmed after reading an XML that was sent before hand.


http://www.cnn.com/video/data/3.0/vi...eam1/index.xml

You can tell it seems to mention rtmpe first and that's the protocol uses in the older version but I do see an rtmpte URL also in that XML but Wireshark claims rtmpte is not in use by default.

[KSV]

Originally Posted by RedPenguin

A wireshark analysis just seems to show normal HTTP/HTTPS traffic then the minute the stream plays a flow of "RTMP" traffic with a ton of "Unknowns (0x0)" which I always seem to see with RTMPE on port 1935, which is confirmed after reading an XML that was sent before hand.

then the only reason possible is that their server is rejecting old clients (handshake 9 and earlier). try with something newer

[KSV]

First post updated with new fixes.

[RedPenguin]

TY.

Only thing that confuses me then after you looked at this issue is how the older rtmpdump involked by rtmpsrv is actually able to download from the stream.

What would the older one have the newer one doesn't, is the question.

[KSV]

Originally Posted by RedPenguin

Only thing that confuses me then after you looked at this issue is how the older rtmpsrv is actually able to download from the stream.

What would the older one have the newer one doesn't, is the question.

First rtmpsrv doesn't download anything. it's only job is to detect parameters and generate proper command line for a given stream and then launch rtmdump (which should be either in same folder or system path).

are you suggesting that older version of rtmpdump is able to download while newer one isn't. there is one more thing we can try. post the debug log of older and newer rtmpdump. rtmpsrv doesn't matter because after the above fix both generates proper command line. introduction of those array types have caused many regressions.