December 2013 - rtmpdump - lists.mplayerhq.hu

[PATCH] Extended timestamp field may be present in type 3 chunk headers
by Martin Panter 03 Mar '14

03 Mar '14

>From c5a88e2ba458588b4b88a4e5b1411c9ee9c03afb Mon Sep 17 00:00:00 2001 From: Martin Panter <vadmium à gmail·com> Date: Wed, 18 Sep 2013 11:58:01 +1000 Subject: [PATCH] Extended timestamp field may be present in type 3 chunk headers MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As described in Adobe’s RTMP specification dated 21 Dec 2012; also: * RTMPY ticket #107, “Compressed headers also can have an extended timestamp”, http://web.archive.org/web/20120624031323/http://dev.rtmpy.org/ticket/107 * https://rarut.wordpress.com/2012/03/21/announcing-nginx-rtmp-module/ This resolves intermittent hangs, segfaults and crashes I was seeing when starting ABC News 24 streams, e.g.: rtmpdump -r rtmp://cp81899.live.edgefcs.net/live/news24-med@28772 --live Some of the packets seemed to contain junk timestamp fields, which often required the extended field. --- Original in case G Mail messes this up: https://github.com/vadmium/rtmpdump/commit/c5a88e2.patch librtmp/rtmp.c | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/librtmp/rtmp.c b/librtmp/rtmp.c index 014ff8b..91ad27f 100644 --- a/librtmp/rtmp.c +++ b/librtmp/rtmp.c @@ -3573,6 +3573,7 @@ RTMP_ReadPacket(RTMP *r, RTMPPacket *packet) char *header = (char *)hbuf; int nSize, hSize, nToRead, nChunk; int didAlloc = FALSE; + int extendedTimestamp; RTMP_Log(RTMP_LOGDEBUG2, "%s: fd=%d", __FUNCTION__, r->m_sb.sb_socket); @@ -3675,17 +3676,19 @@ RTMP_ReadPacket(RTMP *r, RTMPPacket *packet) packet->m_nInfoField2 = DecodeInt32LE(header + 7); } } - if (packet->m_nTimeStamp == 0xffffff) + } + + extendedTimestamp = packet->m_nTimeStamp == 0xffffff; + if (extendedTimestamp) + { + if (ReadN(r, header + nSize, 4) != 4) { - if (ReadN(r, header + nSize, 4) != 4) - { - RTMP_Log(RTMP_LOGERROR, "%s, failed to read extended timestamp", - __FUNCTION__); - return FALSE; - } - packet->m_nTimeStamp = AMF_DecodeInt32(header + nSize); - hSize += 4; + RTMP_Log(RTMP_LOGERROR, "%s, failed to read extended timestamp", + __FUNCTION__); + return FALSE; } + packet->m_nTimeStamp = AMF_DecodeInt32(header + nSize); + hSize += 4; } RTMP_LogHexString(RTMP_LOGDEBUG2, (uint8_t *)hbuf, hSize); @@ -3730,6 +3733,10 @@ RTMP_ReadPacket(RTMP *r, RTMPPacket *packet) if (!r->m_vecChannelsIn[packet->m_nChannel]) r->m_vecChannelsIn[packet->m_nChannel] = malloc(sizeof(RTMPPacket)); memcpy(r->m_vecChannelsIn[packet->m_nChannel], packet, sizeof(RTMPPacket)); + if (extendedTimestamp) + { + r->m_vecChannelsIn[packet->m_nChannel]->m_nTimeStamp = 0xffffff; + } if (RTMPPacket_IsReady(packet)) { -- 1.8.3.4

2 4

Junk CTS Timestamps from C-SPAN1? Did fix in mplayer, but rtmpdump?
by Gunnar 05 Dec '13

05 Dec '13

A week ago CSPAN1 Live started to "chop and stop" when recorded with rtmpdump and played back with mplayer. CSPAN2,3 and their other live channels,streams work OK (as before) http://www.c-span.org/Live-Video/C-SPAN/ rtmp://cp82346.live.edgefcs.net:1935/live and CSPAN1@14845 the Video TImestamp in MPlayer jumps a typical "junk-jump", tens or hundreds of seconds backwards or forwards. Mplayer tries to track, as stopping video, but continues for a while when user steps it a little forward (resets timestamps) Quick brute force fix in mplayer to test the 24 bit CTS (Composition Time Stamp) for "sanity" and zero or set it to something "normal". Usually toggles 30-32 and clear junk-jumps a cple or more seconds apart. It seems Adobe flashplayer does some similar sanity check as it at least does not totally stop the video or then rtmpdump "is at fault". Started to look into - similar brute force sanity check or other solution in rtmpdump, then file cld be played with "normal" mplayers. (- special tool to scan the file and correct the junk-jumps) However, got some google hits on others having similar problem and I'm not really sure abt "all these timestamps and rtmpdump code" Any idea, advice or even some old fix, patch? Gunnar PS Even found some old (pre-library?) code in rtmpdump (rtmp.c Read_1_Packet() appr line 4180) which seemed to "zero the (composition or delta?) timestamp although no sanity-check? But not sure on these Absolute Timestamps and "delta or composition" stamps? Who does what and where does it go? PPS Managed to use brute force on RTMPDUMP also, fund ne place to check CTS for sanity and replaced it with smething more normal.

2 1

Junk CTS Timestamps from C-SPAN1? Did fix in mplayer, but rtmpdump?
by Gunnar 01 Dec '13

01 Dec '13

A week ago CSPAN1 Live started to "chop and stop" when recorded with rtmpdump and played back with mplayer. CSPAN2,3 and their other live channels,streams work OK (as before) http://www.c-span.org/Live-Video/C-SPAN/ rtmp://cp82346.live.edgefcs.net:1935/live and CSPAN1@14845 the Video TImestamp in MPlayer jumps a typical "junk-jump", tens or hundreds of seconds backwards or forwards. Mplayer tries to track, as stopping video, but continues for a while when user steps it a little forward (resets timestamps) Quick brute force fix in mplayer to test the 24 bit CTS (Composition Time Stamp) for "sanity" and zero or set it to something "normal". Usually toggles 30-32 and clear junk-jumps a cple or more seconds apart. It seems Adobe flashplayer does some similar sanity check as it at least does not totally stop the video or then rtmpdump "is at fault". Started to look into - similar brute force sanity check or other solution in rtmpdump, then file cld be played with "normal" mplayers. (- special tool to scan the file and correct the junk-jumps) However, got some google hits on others having similar problem and I'm not really sure abt "all these timestamps and rtmpdump code" Any idea, advice or even some old fix, patch? Gunnar PS Even found some old (pre-library?) code in rtmpdump (rtmp.c Read_1_Packet() appr line 4180) which seemed to "zero the (composition or delta?) timestamp although no sanity-check? But not sure on these Absolute Timestamps and "delta or composition" stamps? Who does what and where does it go?

1 0