I think my last pull request for fixing type 3 extended timestamp was not very rigorous.
First, i use (self.current_header.timestamp >= MAX_INITIAL_TIMESTAMP && self.current_header.timestamp_delta == 0) indicating the previous header was type 0, it's not rigorous as the delta timestamp from rtmp clent maybe zero.
Second, we should not apply extended timestamp of type 3 chunk if the type 3 chunk is not the first chunk of a message.
Maybe we should use timestamp_field which means the 3 bytes timestamp field of message header, then we could know if we will read or write the extended timestamp.
I think my last pull request for fixing type 3 extended timestamp was not very rigorous.
First, i use (self.current_header.timestamp >= MAX_INITIAL_TIMESTAMP && self.current_header.timestamp_delta == 0) indicating the previous header was type 0, it's not rigorous as the delta timestamp from rtmp clent maybe zero.
Second, we should not apply extended timestamp of type 3 chunk if the type 3 chunk is not the first chunk of a message.
Maybe we should use timestamp_field which means the 3 bytes timestamp field of message header, then we could know if we will read or write the extended timestamp.