rtmplite - Project Hosting on Google Code

Yesterday 29 hours ago issue 1 (timestamps get reset to 0) reported by HighlandSun - What steps will reproduce the problem? 1. play an FLV file where two frames have the same absolute timestamp 2. it will send a packet with absolute timestamp=0 3. What is the expected output? What do you see instead? The send routine only gets a relative timestamp passed to it. It should only send an absolute timestamp for the first packet in a stream. What version of the product are you using? On what operating system? 4.0 Linux Please provide any additional information below. The bug is caused by this "or header.time==0" condition at rtmp.py:316 >>> # now figure out the header data bytes if header.streamId != message.streamId or header.time == 0: header.streamId, header.type, header.size, header.time = message.streamId, message.type, message.size, message.time control = Header.FULL <<< The attached patch seems to fix it for me, by insuring that header.time will never be 0 after the first packet in the stream. What steps will reproduce the problem? 1. play an FLV file where two frames have the same absolute timestamp 2. it will send a packet with absolute timestamp=0 3. What is the expected output? What do you see instead? The send routine only gets a relative timestamp passed to it. It should only send an absolute timestamp for the first packet in a stream. What version of the product are you using? On what operating system? 4.0 Linux Please provide any additional information below. The bug is caused by this "or header.time==0" condition at rtmp.py:316 >>> # now figure out the header data bytes if header.streamId != message.streamId or header.time == 0: header.streamId, header.type, header.size, header.time = message.streamId, message.type, message.size, message.time control = Header.FULL <<< The attached patch seems to fix it for me, by insuring that header.time will never be 0 after the first packet in the stream. Last 30 days Dec 01, 2009 r11 (added rtmpclient.py in dist) committed by mamtasingh05 - added rtmpclient.py in dist added rtmpclient.py in dist Dec 01, 2009 r10 (Use new style classes derived from object. Also a bug fix to...) committed by mamtasingh05 - Use new style classes derived from object. Also a bug fix to not create Header() in argument. Use new style classes derived from object. Also a bug fix to not create Header() in argument. Nov 25, 2009 rtmplite-4.0.tgz (Source and example for Flash RTMP server in Python) file uploaded by mamtasingh05 - Labels: Featured Type-Source OpSys-All Labels: Featured Type-Source OpSys-All Earlier this year Sep 17, 2009 r9 (Minor refactoring.) committed by mamtasingh05 - Minor refactoring. Minor refactoring. Sep 16, 2009 r8 (A bug fix in rtmp.py which prevented FLV recording/playback ...) committed by mamtasingh05 - A bug fix in rtmp.py which prevented FLV recording/playback on windows: use "b" mode in open(). Added initial incomplete version of rtmpclient.py. Some minor refactoring in FLV part of rtmp.py A bug fix in rtmp.py which prevented FLV recording/playback on windows: use "b" mode in open(). Added initial incomplete version of rtmpclient.py. Some minor refactoring in FLV part of rtmp.py Sep 03, 2009 r7 (minor comment) committed by mamtasingh05 - minor comment minor comment Jul 11, 2009 rtmplite-3.0.tgz (Added SIP-RTMP gateway module siprtmp, along with some bug f...) file uploaded by mamtasingh05 - Labels: Type-Source OpSys-All Featured Labels: Type-Source OpSys-All Featured Jul 11, 2009 r6 (updated files include in new download) committed by mamtasingh05 - updated files include in new download updated files include in new download Jul 11, 2009 r5 (First version of SIP-RTMP gateway to support Flash to SIP ca...) committed by mamtasingh05 - First version of SIP-RTMP gateway to support Flash to SIP calls and vice versa First version of SIP-RTMP gateway to support Flash to SIP calls and vice versa Jul 10, 2009 r4 (Minor bug fixes, as well as some feature enhancements.) committed by mamtasingh05 - Minor bug fixes, as well as some feature enhancements. Minor bug fixes, as well as some feature enhancements. Jun 29, 2009 r3 (minor updates) committed by mamtasingh05 - minor updates minor updates May 24, 2009 rtmplite-2.0.tgz (Source code of Flash RTMP server in Python 2.5) file uploaded by mamtasingh05 - Labels: Type-Source Featured OpSys-All Labels: Type-Source Featured OpSys-All May 24, 2009 r2 (Renamed the project, and added initial files.) committed by mamtasingh05 - Renamed the project, and added initial files. Renamed the project, and added initial files. May 24, 2009 Project rtmplite created by mamtasingh05 - Flash RTMP server in Python Flash RTMP server in Python

issue 1 (timestamps get reset to 0) reported by HighlandSun - What steps will reproduce the problem? 1. play an FLV file where two frames have the same absolute timestamp 2. it will send a packet with absolute timestamp=0 3. What is the expected output? What do you see instead? The send routine only gets a relative timestamp passed to it. It should only send an absolute timestamp for the first packet in a stream. What version of the product are you using? On what operating system? 4.0 Linux Please provide any additional information below. The bug is caused by this "or header.time==0" condition at rtmp.py:316 >>> # now figure out the header data bytes if header.streamId != message.streamId or header.time == 0: header.streamId, header.type, header.size, header.time = message.streamId, message.type, message.size, message.time control = Header.FULL <<< The attached patch seems to fix it for me, by insuring that header.time will never be 0 after the first packet in the stream.

What steps will reproduce the problem? 1. play an FLV file where two frames have the same absolute timestamp 2. it will send a packet with absolute timestamp=0 3. What is the expected output? What do you see instead? The send routine only gets a relative timestamp passed to it. It should only send an absolute timestamp for the first packet in a stream. What version of the product are you using? On what operating system? 4.0 Linux Please provide any additional information below. The bug is caused by this "or header.time==0" condition at rtmp.py:316 >>> # now figure out the header data bytes if header.streamId != message.streamId or header.time == 0: header.streamId, header.type, header.size, header.time = message.streamId, message.type, message.size, message.time control = Header.FULL <<< The attached patch seems to fix it for me, by insuring that header.time will never be 0 after the first packet in the stream.

Yesterday

Last 30 days

Earlier this year