Please continue to develop rtmpsuck.

[Andik42]

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?

[hyc]

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.

[Andik42]

Originally Posted by hyc

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.

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 :

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.

[Andik42]

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.

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

[hyc]

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.