Audio/video stream recording forums (http://stream-recorder.com/forum/index.php)
-   rtmpdump (http://stream-recorder.com/forum/forumdisplay.php?f=54)
-   -  

Customized rtmpdump binaries with patch file

(http://stream-recorder.com/forum/showthread.php?t=16103)

KSV 04-16-2013 12:57 PM

Re: Customized rtmpdump binaries with patch file


 
Quote:

Originally Posted by RedPenguin (Post 61627)
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 04-16-2013 02:55 PM

Re: Customized rtmpdump binaries with patch file


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

http://pastebin.com/tWJEYA28

KSV 04-17-2013 03:40 AM

Re: Customized rtmpdump binaries with patch file


 
Quote:

Originally Posted by RedPenguin (Post 61630)
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:
Code:

      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:
Code:

      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 04-17-2013 04:34 AM

Re: Customized rtmpdump binaries with patch file


 
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 04-17-2013 05:15 AM

Re: Customized rtmpdump binaries with patch file


 
Quote:

Originally Posted by RedPenguin (Post 61640)
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 04-17-2013 05:35 AM

Re: Customized rtmpdump binaries with patch file


 
Quote:

Originally Posted by KSV (Post 61641)
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 04-17-2013 05:59 AM

Re: Customized rtmpdump binaries with patch file


 
Quote:

Originally Posted by RedPenguin (Post 61642)
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 :rolleyes:

KSV 04-17-2013 07:37 AM

Re: Customized rtmpdump binaries with patch file


 
First post updated with new fixes.

RedPenguin 04-17-2013 01:19 PM

Re: Customized rtmpdump binaries with patch file


 
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 04-17-2013 01:31 PM

Re: Customized rtmpdump binaries with patch file


 
Quote:

Originally Posted by RedPenguin (Post 61653)
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.


All times are GMT -6. The time now is 08:10 AM.