fix rtmp protocol bug, use 31bits timestamp

@@ -1023,16 +1023,6 @@ int SrsProtocol::read_message_header(SrsChunkStream* chunk, char fmt, int bh_siz
 			return ret;
 			return ret;
 		}
 		}
 
 
-		// ffmpeg/librtmp may donot send this filed, need to detect the value.
-		// @see also: http://blog.csdn.net/win_lin/article/details/13363699
-		// the extended-timestamp must be unsigned-int,
-		// 		24bits timestamp: 0xffffff = 16777215ms = 16777.215s = 4.66h
-		// 		32bits timestamp: 0xffffffff = 4294967295ms = 4294967.295s = 1193.046h = 49.71d
-		// because the rtmp protocol says the 32bits timestamp is about "50 days":
-		// 		3. Byte Order, Alignment, and Time Format
-		//				Because timestamps are generally only 32 bits long, they will roll
-		//				over after fewer than 50 days.
-		// so, use u_int32_t is right.
 		u_int32_t timestamp = 0x00;
 		u_int32_t timestamp = 0x00;
         char* pp = (char*)&timestamp;
         char* pp = (char*)&timestamp;
         pp[3] = *p++;
         pp[3] = *p++;
@@ -1052,6 +1042,30 @@ int SrsProtocol::read_message_header(SrsChunkStream* chunk, char fmt, int bh_siz
 		srs_verbose("header read ext_time completed. time=%"PRId64"", chunk->header.timestamp);
 		srs_verbose("header read ext_time completed. time=%"PRId64"", chunk->header.timestamp);
 	}
 	}
 	
 	
+	// ffmpeg/librtmp may donot send this filed, need to detect the value.
+	// @see also: http://blog.csdn.net/win_lin/article/details/13363699
+	// the extended-timestamp must be unsigned-int,
+	// 		24bits timestamp: 0xffffff = 16777215ms = 16777.215s = 4.66h
+	// 		32bits timestamp: 0xffffffff = 4294967295ms = 4294967.295s = 1193.046h = 49.71d
+	// because the rtmp protocol says the 32bits timestamp is about "50 days":
+	// 		3. Byte Order, Alignment, and Time Format
+	//				Because timestamps are generally only 32 bits long, they will roll
+	//				over after fewer than 50 days.
+	// 
+	// but, its sample says the timestamp is 31bits:
+	// 		An application could assume, for example, that all 
+	//		adjacent timestamps are within 2^31 milliseconds of each other, so
+	//		10000 comes after 4000000000, while 3000000000 comes before
+	//		4000000000.
+	// and flv specification says timestamp is 31bits:
+	//		Extension of the Timestamp field to form a SI32 value. This
+	//		field represents the upper 8 bits, while the previous
+	//		Timestamp field represents the lower 24 bits of the time in
+	//		milliseconds.
+	// in a word, 31bits timestamp is ok.
+    // convert extended timestamp to 31bits.
+    chunk->header.timestamp &= 0x7fffffff;
+	
 	// valid message
 	// valid message
 	if (chunk->header.payload_length < 0) {
 	if (chunk->header.payload_length < 0) {
 		ret = ERROR_RTMP_MSG_INVLIAD_SIZE;
 		ret = ERROR_RTMP_MSG_INVLIAD_SIZE;