mirror of
https://github.com/ossrs/srs.git
synced 2025-03-09 15:49:59 +00:00
fix rtmp protocol bug, use 31bits timestamp
This commit is contained in:
parent
741d6f97f6
commit
c89aea8af7
1 changed files with 24 additions and 10 deletions
|
@ -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*)×tamp;
|
char* pp = (char*)×tamp;
|
||||||
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;
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue