对于0xC这种后续的chunk包的extended timestamp该不该发,rtmp协议中说是不发,但是FMLE是发的,推流超过4.5小时就需要用extended timestamp了。
rtmpdump里面的librtmp,不会发这个包,(ffmpeg里面用--enable-librtmp就会使用这个rtmp的库),而且是在开始就会发这个包。
6.1.3. Extended Timestamp
This field is transmitted only when the normal time stamp in the
chunk message header is set to 0x00ffffff. If normal time stamp is
set to any value less than 0x00ffffff, this field MUST NOT be
present. This field MUST NOT be present if the timestamp field is not
present. Type 3 chunks MUST NOT have this field.
有可能是adobe变更了这个协议,也就是说,FMLE给FMS,FMS给flash-player,都是带这个时间戳的。
收包时,服务器端则需要检测下,若接下来的4字节不是extended timestamp,那么就忽略就好了。
发包时,只能采取配置,要么发,要么不发。默认发就好了。
看nginx-rtmp代码:
ngx_rtmp_recv(ngx_event_t *rev) { for( ;; ) { /* parse headers */ if (b->pos == b->start) { /* chunk basic header */ fmt = (*p >> 6) & 0x03; csid = *p++ & 0x3f; if (fmt <= 2 ) { /* timestamp: big-endian 3b -> little-endian 4b */ pp = (u_char*)timestamp; ext = (timestamp == 0x00ffffff); if (fmt <= 1) { /* size: big-endian 3b -> little-endian 4b type*/ pp = (u_char*)&h->mlen; h->type = *(uint8_t*)p++; if (fmt == 0) { /* stream: little-endian 4b -> little-endian 4b */ pp = (u_char*)&h->msid; } } } /* extended header */ if (ext) { pp = (u_char*)timestamp; pp[3] = *p++; pp[2] = *p++; pp[1] = *p++; pp[0] = *p++; }可见,不管是什么chunk,只要有extended-timestamp,nginx-rtmp都会读这个。所以nginx-rtmp对接FMLE是没有问题的,对接librtmp有问题。
更好的做法是判断下读出来的extended timestamp是否是和之前的一样,如果不是一样说明没有发,就忽略。
nginx-rtmp发包的逻辑:
ngx_rtmp_prepare_message { /* create fmt3 header for successive fragments */ thsize = p - out->buf->pos; ngx_memcpy(th, out->buf->pos, thsize); th[0] |= 0xc0; /* message header */ if (fmt <= 2) { } /* extended header */ if (ext_timestamp) { pp = (u_char*)&ext_timestamp; *p++ = pp[3]; *p++ = pp[2]; *p++ = pp[1]; *p++ = pp[0]; /* This CONTRADICTS the standard * but that's the way flash client * wants data to be encoded; * ffmpeg complains */ if (cscf->play_time_fix) { ngx_memcpy(&th[thsize], p - 4, 4); thsize += 4; } }
nginx-rtmp还特意说明了flash客户端就是和rtmp规范不一样。
out->buf->pos就是指向包的第一个chunk,若有extended-timestamp,那么肯定会在第一个包加上extended timestamp;后面还有个th和thsize,就是给后续的type=3的chunk包的,会加上这4字节的extended timestamp:
/* This CONTRADICTS the standard * but that's the way flash client * wants data to be encoded; * ffmpeg complains */ if (cscf->play_time_fix) { ngx_memcpy(&th[thsize], p - 4, 4); thsize += 4; } /* append headers to successive fragments */ for(out = out->next; out; out = out->next) { out->buf->pos -= thsize; ngx_memcpy(out->buf->pos, th, thsize); }
另外,把chunksize设置大一点,最大是65536,避免发type=3的chunk包,也是一个很好的方法。不过视频的I帧一般较大,超过64KB也有可能。
The maximum chunk size can be 65536 bytes and minimum 128 bytes.
按照这种规则,即type=3的chunk也发extended-timestamp,是没有问题:
FMLE一直没有断开,客户端也没有断开。
服务器端是srs(simple rtmp server),也没有断开:
时间已经超过了24位,使用extended-timestamp:
(gdb) p /x 21039918 $1 = 0x1410b2e
而nginx呢,是采用第一个包发完全的extended-timestamp,但是后续都是发type=1的chunk,即时间戳差值。