tosinbot / rtmplite

Automatically exported from code.google.com/p/rtmplite
0 stars 0 forks source link

timestamps get reset to 0 #1

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
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.

Original issue reported on code.google.com by Highland...@gmail.com on 17 Dec 2009 at 8:54

Attachments:

GoogleCodeExporter commented 8 years ago
This was fixed long time ago when timestamp part of rtmp was reworked...

Original comment by kundan10 on 27 Oct 2011 at 3:14