[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]

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_210 0kbps_320aac.mp4?s=1269265400&e=1269265820&h=25971538d5e6f42ccbe6fd960f77cd7e
Saving as: 20081106_Brahms_Sinfonie2excerpt_H264_1280x720_210 0kbps_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.