Please continue to develop rtmpsuck.

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

Please continue to develop rtmpsuck.

Thanks to the developers for the great work.
I was able to use rtmpsuck version 2.2 under Linux with great success.
Now version 2.2a is completely broken.
No large file support. Not a single header is recognized anymore.
I'm aware of the fact that rtmpsuck is more or less unusable for Windows. But is the first choice for Linux, everything works automatically.

Will rtmpsuck be updated, so it will be usable again?

Re: Please continue to develop rtmpsuck.

Yeah, unfortunately some last minute changes for 2.2a broke things. Try the svn trunk instead, most of the problems are fixed now. If you get a crash, tget a stack trace from the crash and post it to the mailing list.

Re: Please continue to develop rtmpsuck.

Quote:

Originally Posted by hyc (Post 17474)

Thanks, much better with revision 393 now. But it still does not work.

Here is the URL that I've tested.

_http://dch.berliner-philharmoniker.de/#/en/tour/

The navigation is Flash based, you have to press "go to stream test".
And yes, it is unencrypted.

Here are the last lines of debug output :

Code:

DEBUG: ServeInvoke, client invoking <play>

Playpath: mp4:s/streamtest/20081106_Brahms_Sinfonie2excerpt_H264_1280x720_2100kbps_320aac.mp4?s=1269265400&e=1269265820&h=25971538d5e6f42ccbe6fd960f77cd7e

Saving as: 20081106_Brahms_Sinfonie2excerpt_H264_1280x720_2100kbps_320aac.mp4

DEBUG2: RTMP_SendPacket: fd=5, size=182

  0000:  08 00 00 f6 00 00 b6 14  01 00 00 00               ............

  0000:  02 00 04 70 6c 61 79 00  00 00 00 00 00 00 00 00   ...play.........

  0010:  05 02 00 90 6d 70 34 3a  73 2f 73 74 72 65 61 6d   ....mp4:s/stream

  0020:  74 65 73 74 2f 32 30 30  38 31 31 30 36 5f 42 72   test/20081106_Br

  0030:  61 68 6d 73 5f 53 69 6e  66 6f 6e 69 65 32 65 78   ahms_Sinfonie2ex

  0040:  63 65 72 70 74 5f 48 32  36 34 5f 31 32 38 30 78   cerpt_H264_1280x

  0050:  37 32 30 5f 32 31 30 30  6b 62 70 73 5f 33 32 30   720_2100kbps_320

  0060:  61 61 63 2e 6d 70 34 3f  73 3d 31 32 36 39 32 36   aac.mp4?s=126926

  0070:  35 34 30 30 26 65 3d 31  32 36 39 32 36 35 38 32   5400&e=126926582

  0000:  c8                                                 .

  0000:  30 26 68 3d 32 35 39 37  31 35 33 38 64 35 65 36   0&h=25971538d5e6

  0010:  66 34 32 63 63 62 65 36  66 64 39 36 30 66 37 37   f42ccbe6fd960f77

  0020:  63 64 37 65 00 00 00 00  00 00 00 00 00 00 c0 8f   cd7e............

  0030:  40 00 00 00 00 00                                  @.....

DEBUG: Invoking play

DEBUG2: RTMP_ReadPacket: fd=5

DEBUG2: RTMP_SendPacket: fd=5, size=34

  0000:  43 ff ff ff 00 00 22 14  ff ff ff 0a               C.....".....

  0000:  02 00 0c 64 65 6c 65 74  65 53 74 72 65 61 6d 00   ...deleteStream.

  0010:  3f f0 00 00 00 00 00 00  05 00 3f f0 00 00 00 00   ?.........?.....

  0020:  00 00                                              ..

ERROR: WriteN, RTMP send error 32 (46 bytes)

ERROR: RTMP_ReadPacket, failed to read RTMP packet header

It looks like the stream is closed from our side.

Re: Please continue to develop rtmpsuck.

I guess there is a bug with 32 bit time stamps.
I've just turned off using the difference to the last time stamp.
At least the site mentioned in the previous post now works again.

Code:

Index: librtmp/rtmp.c

===================================================================

--- librtmp/rtmp.c      (revision 393)

+++ librtmp/rtmp.c      (working copy)

@@ -2594,7 +2594,7 @@

       if (prevPacket->m_nInfoField1 == packet->m_nInfoField1

          && packet->m_headerType == RTMP_PACKET_SIZE_SMALL)

        packet->m_headerType = RTMP_PACKET_SIZE_MINIMUM;

-      last = prevPacket->m_nInfoField1;

+      /*last = prevPacket->m_nInfoField1;*/

     }



   if (packet->m_headerType > 3)        // sanity

Re: Please continue to develop rtmpsuck.

Thanks for the followup. This is a drag though, because that patch was required to make RTMP_Write() work. Perhaps there's a different bug involved here, maybe the timestamps are not being set correctly on the input side...

Hmmm, I just tried that stream test and it worked fine here without any other patching.

Never mind, there was a problem in the timestamps. Fixed now.