December 2011 - rtmpdump - lists.mplayerhq.hu

[PATCH] Add support for building with gnutls with nettle as backend
by Martin Storsjo 27 Feb '12

27 Feb '12

--- Since gnutls 2.12, they default to nettle instead of gcrypt as default crypto backend. Since librtmp uses some of the crypto functions directly, this needs updates here. Implemented this by adding another CRYPTO option, GNUTLS_NETTLE. This is totally untested, since I don't really have access to any such rtmp streams that require use of the crypto libraries. Makefile | 1 + librtmp/Makefile | 3 +++ librtmp/dh.h | 20 +++++++++++++++++++- librtmp/handshake.h | 20 ++++++++++++++++++++ librtmp/hashswf.c | 11 +++++++++++ librtmp/rtmp.c | 4 ++-- librtmp/rtmp_sys.h | 2 +- 7 files changed, 57 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 6ef5742..0cf41be 100644 --- a/Makefile +++ b/Makefile @@ -13,6 +13,7 @@ CRYPTO=OPENSSL #CRYPTO=GNUTLS LIBZ=-lz LIB_GNUTLS=-lgnutls -lgcrypt $(LIBZ) +LIB_GNUTLS_NETTLE=-lgnutls -lhogweed -lnettle -lgmp $(LIBZ) LIB_OPENSSL=-lssl -lcrypto $(LIBZ) LIB_POLARSSL=-lpolarssl $(LIBZ) CRYPTO_LIB=$(LIB_$(CRYPTO)) diff --git a/librtmp/Makefile b/librtmp/Makefile index a0125f1..353c6c8 100644 --- a/librtmp/Makefile +++ b/librtmp/Makefile @@ -21,14 +21,17 @@ CRYPTO=OPENSSL DEF_POLARSSL=-DUSE_POLARSSL DEF_OPENSSL=-DUSE_OPENSSL DEF_GNUTLS=-DUSE_GNUTLS +DEF_GNUTLS_NETTLE=-DUSE_GNUTLS_NETTLE DEF_=-DNO_CRYPTO REQ_GNUTLS=gnutls +REQ_GNUTLS_NETTLE=gnutls REQ_OPENSSL=libssl,libcrypto LIBZ=-lz LIBS_posix= LIBS_darwin= LIBS_mingw=-lws2_32 -lwinmm -lgdi32 LIB_GNUTLS=-lgnutls -lgcrypt $(LIBZ) +LIB_GNUTLS_NETTLE=-lgnutls -lhogweed -lnettle -lgmp $(LIBZ) LIB_OPENSSL=-lssl -lcrypto $(LIBZ) LIB_POLARSSL=-lpolarssl $(LIBZ) PRIVATE_LIBS=$(LIBS_$(SYS)) diff --git a/librtmp/dh.h b/librtmp/dh.h index efef0fd..5d0739f 100644 --- a/librtmp/dh.h +++ b/librtmp/dh.h @@ -77,7 +77,8 @@ static int MDH_compute_key(uint8_t *secret, size_t len, MP_t pub, MDH *dh) return 0; } -#elif defined(USE_GNUTLS) +#elif defined(USE_GNUTLS) || defined(USE_GNUTLS_NETTLE) +#ifdef USE_GNUTLS #include <gcrypt.h> typedef gcry_mpi_t MP_t; #define MP_new(m) m = gcry_mpi_new(1) @@ -92,6 +93,23 @@ typedef gcry_mpi_t MP_t; #define MP_bytes(u) (gcry_mpi_get_nbits(u) + 7) / 8 #define MP_setbin(u,buf,len) gcry_mpi_print(GCRYMPI_FMT_USG,buf,len,NULL,u) #define MP_getbin(u,buf,len) gcry_mpi_scan(&u,GCRYMPI_FMT_USG,buf,len,NULL) +#else +#include <gmp.h> +#include <nettle/bignum.h> +typedef mpz_ptr MP_t; +#define MP_new(m) m = malloc(sizeof(*m)); mpz_init2(m, 1) +#define MP_set_w(mpi, w) mpz_set_ui(mpi, w) +#define MP_cmp(u, v) mpz_cmp(u, v) +#define MP_set(u, v) mpz_set(u, v) +#define MP_sub_w(mpi, w) mpz_sub_ui(mpi, mpi, w) +#define MP_cmp_1(mpi) mpz_cmp_ui(mpi, 1) +#define MP_modexp(r, y, q, p) mpz_powm(r, y, q, p) +#define MP_free(mpi) free(mpi) +#define MP_gethex(u, hex, res) res = (mpz_set_str(u, hex, 16) == 0) +#define MP_bytes(u) mpz_sizeinbase(u, 8) +#define MP_setbin(u,buf,len) nettle_mpz_get_str_256(len,buf,u) +#define MP_getbin(u,buf,len) nettle_mpz_set_str_256_u(u,len,buf) +#endif typedef struct MDH { MP_t p; diff --git a/librtmp/handshake.h b/librtmp/handshake.h index 98bf3c8..354c419 100644 --- a/librtmp/handshake.h +++ b/librtmp/handshake.h @@ -59,6 +59,26 @@ typedef gcry_cipher_hd_t RC4_handle; #define RC4_encrypt2(h,l,s,d) gcry_cipher_encrypt(h,(void *)d,l,(void *)s,l) #define RC4_free(h) gcry_cipher_close(h) +#elif defined(USE_GNUTLS_NETTLE) +#include <nettle/hmac.h> +#include <nettle/arcfour.h> +#ifndef SHA256_DIGEST_LENGTH +#define SHA256_DIGEST_LENGTH 32 +#endif +#undef HMAC_CTX +#define HMAC_CTX struct hmac_sha256_ctx +#define HMAC_setup(ctx, key, len) hmac_sha256_set_key(&ctx, len, key) +#define HMAC_crunch(ctx, buf, len) hmac_sha256_update(&ctx, len, buf) +#define HMAC_finish(ctx, dig, dlen) dlen = SHA256_DIGEST_LENGTH; hmac_sha256_digest(&ctx, SHA256_DIGEST_LENGTH, dig) +#define HMAC_close(ctx) + +typedef struct arcfour_ctx* RC4_handle; +#define RC4_alloc(h) *h = malloc(sizeof(struct arcfour_ctx)) +#define RC4_setkey(h,l,k) arcfour_set_key(h, l, k) +#define RC4_encrypt(h,l,d) arcfour_crypt(h,l,(uint8_t *)d,(uint8_t *)d) +#define RC4_encrypt2(h,l,s,d) arcfour_crypt(h,l,(uint8_t *)s,(uint8_t *)d) +#define RC4_free(h) free(h) + #else /* USE_OPENSSL */ #include <openssl/sha.h> #include <openssl/hmac.h> diff --git a/librtmp/hashswf.c b/librtmp/hashswf.c index 3c56b69..ca2084c 100644 --- a/librtmp/hashswf.c +++ b/librtmp/hashswf.c @@ -52,6 +52,17 @@ #define HMAC_crunch(ctx, buf, len) gcry_md_write(ctx, buf, len) #define HMAC_finish(ctx, dig, dlen) dlen = SHA256_DIGEST_LENGTH; memcpy(dig, gcry_md_read(ctx, 0), dlen) #define HMAC_close(ctx) gcry_md_close(ctx) +#elif defined(USE_GNUTLS_NETTLE) +#include <nettle/hmac.h> +#ifndef SHA256_DIGEST_LENGTH +#define SHA256_DIGEST_LENGTH 32 +#endif +#undef HMAC_CTX +#define HMAC_CTX struct hmac_sha256_ctx +#define HMAC_setup(ctx, key, len) hmac_sha256_set_key(&ctx, len, key) +#define HMAC_crunch(ctx, buf, len) hmac_sha256_update(&ctx, len, buf) +#define HMAC_finish(ctx, dig, dlen) dlen = SHA256_DIGEST_LENGTH; hmac_sha256_digest(&ctx, SHA256_DIGEST_LENGTH, dig) +#define HMAC_close(ctx) #else /* USE_OPENSSL */ #include <openssl/ssl.h> #include <openssl/sha.h> diff --git a/librtmp/rtmp.c b/librtmp/rtmp.c index df2cb27..c9d5c83 100644 --- a/librtmp/rtmp.c +++ b/librtmp/rtmp.c @@ -34,7 +34,7 @@ #ifdef CRYPTO #ifdef USE_POLARSSL #include <polarssl/havege.h> -#elif defined(USE_GNUTLS) +#elif defined(USE_GNUTLS) || defined(USE_GNUTLS_NETTLE) #include <gnutls/gnutls.h> #else /* USE_OPENSSL */ #include <openssl/ssl.h> @@ -204,7 +204,7 @@ RTMP_TLS_Init() /* Do this regardless of NO_SSL, we use havege for rtmpe too */ RTMP_TLS_ctx = calloc(1,sizeof(struct tls_ctx)); havege_init(&RTMP_TLS_ctx->hs); -#elif defined(USE_GNUTLS) && !defined(NO_SSL) +#elif (defined(USE_GNUTLS) || defined(USE_GNUTLS_NETTLE)) && !defined(NO_SSL) /* Technically we need to initialize libgcrypt ourselves if * we're not going to call gnutls_global_init(). Ignoring this * for now. diff --git a/librtmp/rtmp_sys.h b/librtmp/rtmp_sys.h index 6a3f215..4958736 100644 --- a/librtmp/rtmp_sys.h +++ b/librtmp/rtmp_sys.h @@ -80,7 +80,7 @@ typedef struct tls_ctx { #define TLS_shutdown(s) ssl_close_notify(s) #define TLS_close(s) ssl_free(s); free(s) -#elif defined(USE_GNUTLS) +#elif defined(USE_GNUTLS) || defined(USE_GNUTLS_NETTLE) #include <gnutls/gnutls.h> typedef struct tls_ctx { gnutls_certificate_credentials_t cred; -- 1.7.3.1

2 8

[PATCH] HTTP_Read not reading full response before parsing.
by KSV 26 Dec '11

26 Dec '11

previous patch does not work well the plain RTMP so i have revised the patch to combine the packet only in case of RTMPT. seems to work well with all url's i have tested so far. one another problem was caused by my avast antivirus. it scans (like most of other antivirus apps) port 80 for web traffic. it was causing the bytes received report not to be sent immediately. for some odd reason it was buffering all those reports and sending them at his own sweet will causing the server to drop connection randomly after few MB's and when server dropped the connection it was flushing all buffered reports at once. if anyone having similar problems, try after disabling your antivirus. revised patch is attached herewith.

1 1

SWFVerification Type 2 request not supported!
by bn 25 Dec '11

25 Dec '11

Hi all, Dailyshow/ColbertReport downloads, which worked fine until a week or so ago, are now failing with "SWFVerification Type 2 request not supported!" Any expertise in resolving this would be appreciated. thanks ----------------------------------------------------------------- rtmpdump --verbose --pageUrl 'http://www.thedailyshow.com/full-episodes/mon-august-1-2011-freida-pinto' --rtmp 'rtmpe://viacomccstrmfs.fplive.net/viacomccstrm/gsp.comedystor/com/dailyshow…' --flv 'The_Daily_Show_Daily_Show__16099_Act_2_080111.flv' --swfhash '4dc6a9e1db35a9c89c380015af28fe80cd7acd259af63315202a50cac7999b05' --swfsize '2022384' --swfUrl 'http://media.mtvnservices.com/mgid:cms:episode:thedailyshow.com:393605' RTMPDump v2.4 (c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL DEBUG: Parsing... DEBUG: Parsed protocol: 2 DEBUG: Parsed host : viacomccstrmfs.fplive.net DEBUG: Parsed app : viacomccstrm/gsp.comedystor DEBUG: Protocol : RTMPE DEBUG: Hostname : viacomccstrmfs.fplive.net DEBUG: Port : 1935 DEBUG: Playpath : mp4:com/dailyshow/TDS/season_16/episode_099/ds_16099_act2_rev_768x432_1720 DEBUG: tcUrl : rtmpe://viacomccstrmfs.fplive.net:1935/viacomccstrm/gsp.comedystor DEBUG: swfUrl : http://media.mtvnservices.com/mgid:cms:episode:thedailyshow.com:393605 DEBUG: pageUrl : http://www.thedailyshow.com/full-episodes/mon-august-1-2011-freida-pinto DEBUG: app : viacomccstrm/gsp.comedystor DEBUG: live : no DEBUG: timeout : 30 sec DEBUG: SWFSHA256: DEBUG: 4d c6 a9 e1 db 35 a9 c8 9c 38 00 15 af 28 fe 80 DEBUG: cd 7a cd 25 9a f6 33 15 20 2a 50 ca c7 99 9b 05 DEBUG: SWFSize : 2022384 DEBUG: Setting buffer time to: 36000000ms Connecting ... DEBUG: RTMP_Connect1, ... connected, handshaking DEBUG: HandShake: Client type: 06 DEBUG: HandShake: DH pubkey position: 472 DEBUG: HandShake: Client digest offset: 1383 DEBUG: HandShake: Initial client digest: DEBUG: e5 99 f2 66 d2 94 48 f4 e5 d2 0c 09 40 79 45 5e DEBUG: 89 16 71 83 cf 77 ff 71 4d f6 0b 41 7f a2 e2 75 DEBUG: HandShake: Type Answer : 09 WARNING: HandShake: Type mismatch: client sent 6, server answered 9 DEBUG: HandShake: Server Uptime : 884713000 DEBUG: HandShake: FMS Version : 3.5.6.1 DEBUG: HandShake: Server DH public key offset: 535 DEBUG: HandShake: Secret key: DEBUG: 6b eb 98 16 1d 5a 15 00 0a c4 fb c6 6b 99 02 e5 DEBUG: 1c 84 31 c0 e5 79 5d 02 8a 5d 7f d7 14 98 38 24 DEBUG: 2f 78 33 5d b5 af 51 87 cf 3e 34 f7 60 36 24 7d DEBUG: 0a 8d 59 fa d1 dc 65 d3 d5 b3 3c 65 21 0f 01 11 DEBUG: 2f 27 92 63 5e c2 e1 1a d6 18 d4 c1 ad 17 ce 2d DEBUG: 73 b7 6f 36 d0 61 16 9f ec 96 e2 6f 25 68 bb da DEBUG: 7b bc b1 98 d8 76 08 e0 c7 9c 49 ba c7 70 12 71 DEBUG: c1 72 19 a6 fb 7c e2 7d 8f 08 38 e2 c3 45 72 6b DEBUG: RC4 Out Key: DEBUG: 7e 4e e1 42 9a 40 2c 19 be 50 48 c4 5c ce db 31 DEBUG: RC4 In Key: DEBUG: 19 1e ef b4 32 b5 04 59 9f 20 d3 f2 e2 af 1f 95 DEBUG: HandShake: Calculated digest key from secure key and server digest: DEBUG: 9a 6b 2d ac 32 fe 25 6b 74 f0 d0 d8 23 f0 ef 36 DEBUG: 34 8b 40 7e 6d 79 ba 3e d7 56 58 99 3b 24 71 8e DEBUG: HandShake: Client signature calculated: DEBUG: 75 57 fc a2 a8 5e ff fe 50 5e 69 3c 24 bd 98 ba DEBUG: 6f 1a eb 1a 66 c8 b5 c6 20 e8 51 42 be fc 23 03 DEBUG: HandShake: Server sent signature: DEBUG: de 5b 29 52 f0 9a 78 1d d6 82 14 27 cb da 1c 4e DEBUG: 9e 53 99 1a 27 bd fb 86 f7 54 04 b0 d2 21 2d df DEBUG: HandShake: Digest key: DEBUG: b7 c9 0b 7d 70 5e d8 fa 19 4c 02 1e 66 e8 55 34 DEBUG: 18 39 89 4f 26 8b ab 1a f2 12 e4 16 ef 73 6e ba DEBUG: HandShake: Signature calculated: DEBUG: de 5b 29 52 f0 9a 78 1d d6 82 14 27 cb da 1c 4e DEBUG: 9e 53 99 1a 27 bd fb 86 f7 54 04 b0 d2 21 2d df DEBUG: HandShake: Genuine Adobe Flash Media Server DEBUG: HandShake: Handshaking finished.... DEBUG: RTMP_Connect1, handshaked DEBUG: Invoking connect INFO: Connected... DEBUG: HandleCtrl, received ctrl. type: 26, len: 3 DEBUG: HandleCtrl, SWFVerification ping received: ERROR: HandleCtrl: SWFVerification Type 2 request not supported! Patches welcome... DEBUG: HandleServerBW: server BW = 2500000 DEBUG: HandleClientBW: client BW = 2500000 2 DEBUG: RTMP_ClientPacket, received: invoke 181 bytes DEBUG: (object begin) DEBUG: Property: NULL DEBUG: (object begin) DEBUG: Property: <Name: level, STRING: error> DEBUG: Property: <Name: code, STRING: NetConnection.Connect.Rejected> DEBUG: Property: <Name: description, STRING: Connection failed.> DEBUG: Property: <Name: description, STRING: [ Client.SWFVerificiation.Rejected ] : status code 434> DEBUG: (object end) DEBUG: (object end) DEBUG: HandleInvoke, server invoking <_error> ERROR: rtmp server sent error DEBUG: RTMP_ClientPacket, received: invoke 18 bytes DEBUG: (object begin) DEBUG: Property: NULL DEBUG: (object end) DEBUG: HandleInvoke, server invoking <close> ERROR: rtmp server requested close DEBUG: Closing connection. -----------------------------------------------------------------

6 8

[PATCH] AMF_GetProp return garbage for non existent properties
by KSV 25 Dec '11

25 Dec '11

AMF_GetProp uses wrong index value for accessing the non existent property and returns garbage instead of AMFProp_Invalid. attached patch fixes the problem.

1 2

[PATCH] HTTP_Read not reading full response before parsing.
by KSV 23 Dec '11

23 Dec '11

Test url: rtmpdump -r "rtmpt://ll2.workcast.net:80/vod1/mp4:Game300-LanguageXXX-Rec2_0_20110828151412811_1.mp4" -W "http://c466722.workcast.net/flowplayer.commercial-3.2.5.swf" -p "http://video.homelessworldcup.org/AuditoriumUsher.aspx?pak=6733772765126804… 2165343567627" -o "VideoName.mp4" i above test case server is sending the initial response broken in two tcp segments of length 145 and remaining. HTTP_Read consideres anything above 144 as complete response and parses it incorrectly which results in no client id being parsed which is necessary for further communication. attached patch tries to fix it by reading small packets in one go (handshake, commands, pings) and leave larger packets alone (audio, video). @hyc however even after applying the above fix i am still unable to download the video. it handshakes with server but server is rejecting second part of handshake. is it new type of rtmp handshake?

2 3

branch master updated. 4e06e21 Support decoding AMF_XML_DOC
by gil＠avcodec.org 23 Dec '11

23 Dec '11

The branch, master has been updated via 4e06e218e230a86608637b613499984703a342cf (commit) from 5d03a4f0d6216da92830306436eae7eb318d5115 (commit) - Log ----------------------------------------------------------------- commit 4e06e218e230a86608637b613499984703a342cf Author: Antti Ajanki <antti.ajanki(a)iki.fi> AuthorDate: Thu Dec 22 17:54:10 2011 -0800 Commit: Howard Chu <hyc(a)highlandsun.com> CommitDate: Thu Dec 22 17:54:10 2011 -0800 Support decoding AMF_XML_DOC MF_XML_DOC data is an XML document which is encoded similarly to a long string. diff --git a/librtmp/amf.c b/librtmp/amf.c index f9ecf21..659421e 100644 --- a/librtmp/amf.c +++ b/librtmp/amf.c @@ -735,13 +735,15 @@ AMFProp_Decode(AMFObjectProperty *prop, const char *pBuffer, int nSize, break; } case AMF_LONG_STRING: + case AMF_XML_DOC: { unsigned int nStringSize = AMF_DecodeInt32(pBuffer); if (nSize < (long)nStringSize + 4) return -1; AMF_DecodeLongString(pBuffer, &prop->p_vu.p_aval); nSize -= (4 + nStringSize); - prop->p_type = AMF_STRING; + if (prop->p_type == AMF_LONG_STRING) + prop->p_type = AMF_STRING; break; } case AMF_RECORDSET: @@ -750,12 +752,6 @@ AMFProp_Decode(AMFObjectProperty *prop, const char *pBuffer, int nSize, return -1; break; } - case AMF_XML_DOC: - { - RTMP_Log(RTMP_LOGERROR, "AMF_XML_DOC not supported!"); - return -1; - break; - } case AMF_TYPED_OBJECT: { RTMP_Log(RTMP_LOGERROR, "AMF_TYPED_OBJECT not supported!"); ----------------------------------------------------------------------- Summary of changes: librtmp/amf.c | 10 +++------- 1 files changed, 3 insertions(+), 7 deletions(-) hooks/post-receive --

1 0

[PATCH] Support decoding AMF_XML_DOC
by Antti Ajanki 22 Dec '11

22 Dec '11

AMF_XML_DOC data is an XML document which is encoded similarly to a long string. --- librtmp/amf.c | 10 +++------- 1 files changed, 3 insertions(+), 7 deletions(-) diff --git a/librtmp/amf.c b/librtmp/amf.c index f9ecf21..659421e 100644 --- a/librtmp/amf.c +++ b/librtmp/amf.c @@ -735,13 +735,15 @@ AMFProp_Decode(AMFObjectProperty *prop, const char *pBuffer, int nSize, break; } case AMF_LONG_STRING: + case AMF_XML_DOC: { unsigned int nStringSize = AMF_DecodeInt32(pBuffer); if (nSize < (long)nStringSize + 4) return -1; AMF_DecodeLongString(pBuffer, &prop->p_vu.p_aval); nSize -= (4 + nStringSize); - prop->p_type = AMF_STRING; + if (prop->p_type == AMF_LONG_STRING) + prop->p_type = AMF_STRING; break; } case AMF_RECORDSET: @@ -750,12 +752,6 @@ AMFProp_Decode(AMFObjectProperty *prop, const char *pBuffer, int nSize, return -1; break; } - case AMF_XML_DOC: - { - RTMP_Log(RTMP_LOGERROR, "AMF_XML_DOC not supported!"); - return -1; - break; - } case AMF_TYPED_OBJECT: { RTMP_Log(RTMP_LOGERROR, "AMF_TYPED_OBJECT not supported!"); -- 1.7.7.3

1 0

Using rtmpsrv for CSPAN videos results in corrupt flv?
by F G 20 Dec '11

20 Dec '11

Before I start, Thank you for all the hard work that has gone into rtmpdump. :-) I believe I am having the same trouble as sgorwood, described in a message posted in May 2011 (see bottom of email). When attempting to playback CSPAN captures, I receive various errors in different video players, but fairly consistent behavior. As an example, I have tried to capture the same stream sgorwood mentions ( http://www.c-spanvideo.org/program/MobileTechn ), although I experience the same issue with any other stream I attempt to dump. I am using rtmpsrv to capture video, using the following: iptables -t nat -A OUTPUT -p tcp --dport 1935 -m owner \! --uid-owner root -j REDIRECT /home/fosco/rtmpdump/rtmpsrv -V iptables -t nat -D OUTPUT -p tcp --dport 1935 -m owner \! --uid-owner root -j REDIRECT The above command results in a large about of output being scrolled to the terminal during the capture, I have included a short portion below: RTMP Server v2.4 (c) 2010 Andrej Stepanchuk, Howard Chu; license: GPL Streaming on rtmp://0.0.0.0:1935 WARNING: Trying different position for client digest! rtmpdump -r "rtmp://video.c-spanarchives.org:1935/fastplay" -a "fastplay" -f "LNX 11,1,102,55" -W " http://www.c-spanvideo.org/videoLibrary/assets/swf/CSPANPlayer.swf?programi…" -p "http://www.c-spanvideo.org/program/MobileTechn" -y "mp4:full/2011/05/19/20110519200000002_hd.mp4" -o 20110519200000002_hd.flv Closing connection... done! RTMPDump v2.3 (c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL Connecting ... INFO: Connected... Starting download at: 0.000 kB INFO: Metadata: INFO: trackinfo: INFO: timescale 899.00 INFO: length 3239042.00 INFO: language eng INFO: sampledescription: INFO: sampletype avc1 INFO: timescale 44100.00 INFO: length 158852096.00 INFO: language eng INFO: sampledescription: INFO: sampletype mp4a INFO: audiochannels 2.00 INFO: audiosamplerate 44100.00 INFO: videoframerate 899.00 INFO: aacaot 2.00 INFO: avclevel 31.00 INFO: avcprofile 77.00 INFO: audiocodecid mp4a INFO: videocodecid avc1 INFO: width 960.00 INFO: height 540.00 INFO: frameWidth 960.00 INFO: frameHeight 540.00 INFO: displayWidth 960.00 INFO: displayHeight 540.00 INFO: framerate 22.48 INFO: moovposition 289080973.00 INFO: duration 3602.94 226.928 kB / 2.89 sec (0.0%) INFO: Metadata: INFO: trackinfo: INFO: timescale 899.00 INFO: length 3239042.00 INFO: language eng INFO: sampledescription: INFO: sampletype avc1 INFO: timescale 44100.00 INFO: length 158852096.00 INFO: language eng INFO: sampledescription: INFO: sampletype mp4a INFO: audiochannels 2.00 INFO: audiosamplerate 44100.00 INFO: videoframerate 899.00 INFO: aacaot 2.00 INFO: avclevel 31.00 INFO: avcprofile 77.00 INFO: audiocodecid mp4a INFO: videocodecid avc1 INFO: width 960.00 INFO: height 540.00 INFO: frameWidth 960.00 INFO: frameHeight 540.00 INFO: displayWidth 960.00 INFO: displayHeight 540.00 INFO: framerate 22.48 INFO: moovposition 289080973.00 INFO: duration 3602.94 403.361 kB / 8.01 sec (0.2%) INFO: Metadata: INFO: trackinfo: INFO: timescale 899.00 INFO: length 3239042.00 INFO: language eng INFO: sampledescription: INFO: sampletype avc1 INFO: timescale 44100.00 INFO: length 158852096.00 INFO: language eng INFO: sampledescription: INFO: sampletype mp4a INFO: audiochannels 2.00 INFO: audiosamplerate 44100.00 INFO: videoframerate 899.00 INFO: aacaot 2.00 INFO: avclevel 31.00 INFO: avcprofile 77.00 INFO: audiocodecid mp4a INFO: videocodecid avc1 INFO: width 960.00 INFO: height 540.00 INFO: frameWidth 960.00 INFO: frameHeight 540.00 INFO: displayWidth 960.00 INFO: displayHeight 540.00 INFO: framerate 22.48 INFO: moovposition 289080973.00 INFO: duration 3602.94 1237.523 kB / 26.43 sec (0.7%) INFO: Metadata: INFO: trackinfo: INFO: timescale 899.00 INFO: length 3239042.00 INFO: language eng INFO: sampledescription: INFO: sampletype avc1 INFO: timescale 44100.00 INFO: length 158852096.00 INFO: language eng INFO: sampledescription: INFO: sampletype mp4a INFO: audiochannels 2.00 INFO: audiosamplerate 44100.00 INFO: videoframerate 899.00 INFO: aacaot 2.00 INFO: avclevel 31.00 INFO: avcprofile 77.00 INFO: audiocodecid mp4a INFO: videocodecid avc1 INFO: width 960.00 INFO: height 540.00 INFO: frameWidth 960.00 INFO: frameHeight 540.00 INFO: displayWidth 960.00 INFO: displayHeight 540.00 INFO: framerate 22.48 INFO: moovposition 289080973.00 INFO: duration 3602.94 1390.485 kB / 22.64 sec (0.6%) INFO: Metadata: INFO: trackinfo: INFO: timescale 899.00 INFO: length 3239042.00 INFO: language eng INFO: sampledescription: INFO: sampletype avc1 INFO: timescale 44100.00 INFO: length 158852096.00 INFO: language eng INFO: sampledescription: INFO: sampletype mp4a INFO: audiochannels 2.00 INFO: audiosamplerate 44100.00 INFO: videoframerate 899.00 INFO: aacaot 2.00 INFO: avclevel 31.00 INFO: avcprofile 77.00 INFO: audiocodecid mp4a INFO: videocodecid avc1 INFO: width 960.00 INFO: height 540.00 INFO: frameWidth 960.00 INFO: frameHeight 540.00 INFO: displayWidth 960.00 INFO: displayHeight 540.00 INFO: framerate 22.48 INFO: moovposition 289080973.00 INFO: duration 3602.94 2000.680 kB / 36.40 sec (1.0%) ... During playback of the capture, the video jumps backwards a few seconds upon hitting the mentioned errors, and continues playing from that point. This happens over and over, causing the video to slowly progress forward, after repeating sections multiple times. in mplayer: *fosco@grubb:~/cspan$ mplayer 20110519200000002_hd.flv * MPlayer 1.0rc4-4.4.5 (C) 2000-2010 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing 20110519200000002_hd.flv. libavformat file format detected. *[flv @ 0x1f59880]Estimating duration from bitrate, this may be inaccurate* [lavf] stream 0: video (h264), -vid 0 [lavf] stream 1: audio (aac), -aid 0 VIDEO: [H264] 960x540 0bpp 44.917 fps 0.0 kbps ( 0.0 kbyte/s) Clip info: audiochannels: 2 audiosamplerate: 44100 videoframerate: 899 aacaot: 2 avclevel: 31 avcprofile: 77 audiocodecid: mp4a videocodecid: avc1 width: 960 height: 540 frameWidth: 960 frameHeight: 540 displayWidth: 960 displayHeight: 540 framerate: 22 moovposition: 289080973 duration: 3603 open: No such file or directory [MGA] Couldn't open: /dev/mga_vid open: No such file or directory [MGA] Couldn't open: /dev/mga_vid [VO_TDFXFB] Can't open /dev/fb0: No such file or directory. [VO_3DFX] Unable to open /dev/3dfx. Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory [vdpau] Error when calling vdp_device_create_x11: 1 ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) ========================================================================== ========================================================================== Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding) FAAD: compressed input bitrate missing, assuming 128kbit/s! AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400) Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio)) ========================================================================== AO: [pulse] 44100Hz 2ch s16le (2 bytes per sample) Starting playback... Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 960x540 => 960x540 Planar YV12 *[h264 @ 0x7ffa62083020]number of reference frames exceeds max (probably corrupt input), discarding one* *[h264 @ 0x7ffa62083020]number of reference frames exceeds max (probably corrupt input), discarding one* *[h264 @ 0x7ffa62083020]reference picture missing during reorder* *[h264 @ 0x7ffa62083020]Missing reference picture* *[h264 @ 0x7ffa62083020]reference picture missing during reorder5 0 * *[h264 @ 0x7ffa62083020]Missing reference picture* *A: 27.6 V: 25.1 A-V: 2.464 ct: -0.289 0/ 0 4% 0% 0.6% 50 0 * ************************************************ **** Your system is too SLOW to play this! **** ************************************************ Possible reasons, problems, workarounds: - Most common: broken/buggy _audio_ driver - Try -ao sdl or use the OSS emulation of ALSA. - Experiment with different values for -autosync, 30 is a good start. - Slow video output - Try a different -vo driver (-vo help for a list) or try -framedrop! - Slow CPU - Don't try to play a big DVD/DivX on a slow CPU! Try some of the lavdopts, e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all. - Broken file - Try various combinations of -nobps -ni -forceidx -mc 0. - Slow media (NFS/SMB mounts, DVD, VCD etc) - Try -cache 8192. - Are you using -cache to play a non-interleaved AVI file? - Try -nocache. Read DOCS/HTML/en/video.html for tuning/speedup tips. If none of this helps you, read DOCS/HTML/en/bugreports.html. A: 31.1 V: 31.1 A-V: -0.082 ct: -0.278 0/ 0 4% 0% 0.5% 110 0 MPlayer interrupted by signal 2 in module: key_events A: 31.3 V: 31.1 A-V: 0.112 ct: -0.277 0/ 0 4% 0% 0.5% 110 0 Exiting... (Quit) in vlc: *fosco@grubb:~/cspan$ cvlc 20110519200000002_hd.flv * VLC media player 1.1.4 The Luggage (revision exported) Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS") Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE") [0xb67cb0] dummy interface: using the dummy interface module... *[flv @ 0x239ca30]Estimating duration from bitrate, this may be inaccurate* *[flv @ 0x7f1154016c80]Estimating duration from bitrate, this may be inaccurate* *[0x176e840] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 300 ms)* *number of reference frames exceeds max (probably corrupt input), discarding one* *number of reference frames exceeds max (probably corrupt input), discarding one* *number of reference frames exceeds max (probably corrupt input), discarding one* *number of reference frames exceeds max (probably corrupt input), discarding one* Referenced Email from May 2011: [rtmpdump] Can't get rtmpdump to work with CSPAN*Steve Gorwood* sgorwood at swbell.net <rtmpdump%40mplayerhq.hu?Subject=Re%3A%20%5Brtmpdump%5D%20Can%27t%20get%20rtmpdump%20to%20work%20with%20CSPAN&In-Reply-To=%3C201105252354.51303.sgorwood%40swbell.net%3E> *Thu May 26 06:54:51 CEST 2011* - Previous message: [rtmpdump] Trying to dump an rtmp stream<http://lists.mplayerhq.hu/pipermail/rtmpdump/2011-May/001440.html> - *Messages sorted by:* [ date ]<http://lists.mplayerhq.hu/pipermail/rtmpdump/2011-May/date.html#1441> [ thread ]<http://lists.mplayerhq.hu/pipermail/rtmpdump/2011-May/thread.html#1441> [ subject ]<http://lists.mplayerhq.hu/pipermail/rtmpdump/2011-May/subject.html#1441> [ author ]<http://lists.mplayerhq.hu/pipermail/rtmpdump/2011-May/author.html#1441> ------------------------------ I am having trouble downloading CSPAN video using rtmpdump (version 2.3) on kubuntu 11.4. For example, the url: http://www.c-spanvideo.org/program/MobileTechn When I try to use the parameters: rtmpdump -r rtmp://video.c-spanarchives.org:1935/fastplay/../ -y mp4:full/2011/05/19/20110519200000002_hd.mp4 -A 84 -B 3602 -W http://www.c-spanarchives.org/flash/cspanPlayer.swf -o MobileTechn_0.mp4 The dump begins correctly at 2.3%. It proceeds for a while, then drops back and redownloads a portion of the earlier stream. It will do this repeatedly as the dump proceeds so that the final file will contain many repeated segments. I used rtmpsrv to get (hopefully) better parameters. Rtmpsrv gave me the following command line: rtmpdump -r "rtmp://video.c-spanarchives.org:1935/fastplay" -a "fastplay" -f "LNX 10,3,181,14" -W "http://www.c-spanvideo.org/videoLibrary/assets/swf/CSPANPlayer.swf?rand=124…" -p "http://www.c-spanvideo.org/program/MobileTechn" -y "mp4:full/2011/05/19/20110519200000002_hd.mp4" -o 20110519200000002_hd.flv This gave me the same behavior. If I add the -V parameter, I observe that I get the following information at the point of the problem: 7741.721 kB / 158.22 sec (4.3%) DEBUG: HandleCtrl, received ctrl. type: 31, len: 6 DEBUG: HandleCtrl, Stream BufferEmpty 1 DEBUG: HandleCtrl, received ctrl. type: 1, len: 6 DEBUG: HandleCtrl, Stream EOF 1 DEBUG: RTMP_ClientPacket, received: invoke 208 bytes DEBUG: (object begin) DEBUG: Property: NULL DEBUG: (object begin) DEBUG: Property: <Name: level, STRING: status> DEBUG: Property: <Name: code, STRING: NetStream.Pause.Notify> DEBUG: Property: <Name: description, STRING: Pausing full/2011/05/19/20110519200000002_hd.mp4.> DEBUG: Property: <Name: details, STRING: full/2011/05/19/20110519200000002_hd.mp4> DEBUG: Property: <Name: clientid, NUMBER: 504348861.00> DEBUG: (object end) DEBUG: (object end) I have found that if I use the --live parameter, the behavior improves, although I get occasional video corruption. Is there anything that I can do to fix this problem? ------------------------------

3 2

Re: [rtmpdump] [PATCH] url comparison bug
by KSV 20 Dec '11

20 Dec '11

Stef wrote: >Seriously, cmon, it's not big deal! What's a few characters or a bit of pre-parsing going to cost you? and who said it's big deal. i can certainly define required options. however it was certainly unexpected behavior even after using --swfAge 0. Howard Chu wrote: >We should've dropped Windows support. At least Linux users tend to know how to >tinker on their own, instead of whining that it's not Fully AutoMagical. the issue would have been same for non whining linux users. doesn't auto hashing benefits the linux users in same way. Howard Chu wrote: > This was done to accomodate ABC Australia's iView, which uses the same SWF file but with a randomly generated hash in the middle of the URL on each session. Looks like a different solution is needed. wouldn't it be better to check if the url contains iView swf hosting domain and then apply hlen and full url comparison in other cases. i would have written the patch but i am not aware of their swf hosting domains. i tried few free proxies and vpn's but it didn't worked. just for reference see last few posts here for original problem: http://stream-recorder.com/forum/recording-kelby-training-www-kelbytraining…

1 1

What to look for to solve a "handshake failed"?
by rtmpdump＠pepak.net 18 Dec '11

18 Dec '11

Hi! I am trying to download a stream from a provider which recently switched to a new Flash player (the older version worked just fine with RTMPDUMP). Using WireShark I managed to find all? required parameters, and debugging the player I managed to find the secure token. But I am still getting a "handshake failed". Could it mean an unsupported (I am using the latest GIT version of RTMPDUMP) authentication scheme or is there some other expected reason? And if it *is* an unsupported authentication scheme, does it make sense for me to try to decipher it from the player's code? (The player is apparently a version of JWPlayer, but either stripped to the bones or very old, because the SWF is very short and it seems to contain very few scripts, so I think I stand a good chance of finding the scheme, if it can be done from client-side; the only problem is that I have no idea how to add it to RTMPDUMP even if I find it.) If anyone wants to give it a try, the command-line I am using is: rtmpdump -z -v -r "rtmpt://ctv-flv1.content.mediastream.cz/CTv-video" -y "mp4:vypravej/history/139.mp4" -f "WIN 10,3,183,11" -s "http://img8.ceskatelevize.cz/libraries/JWPlayer/player.swf" -W "http://img8.ceskatelevize.cz/libraries/JWPlayer/player.swf" -t "rtmpt://ctv-flv1.content.mediastream.cz/CTv-video" -p "http://www.ceskatelevize.cz/porady/10266819072-vypravej/ve-stopach-doby/197…" -T "5%qp-xvbt+_oi" -o "x.mp4" And I get the following result: RTMPDump v2.4 (c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL DEBUG: Parsing... DEBUG: Parsed protocol: 1 DEBUG: Parsed host : ctv-flv1.content.mediastream.cz DEBUG: Parsed app : CTv-video DEBUG: Protocol : RTMPT DEBUG: Hostname : ctv-flv1.content.mediastream.cz DEBUG: Port : 80 DEBUG: Playpath : mp4:vypravej/history/139.mp4 DEBUG: tcUrl : rtmpt://ctv-flv1.content.mediastream.cz/CTv-video DEBUG: swfUrl : http://img8.ceskatelevize.cz/libraries/JWPlayer/player.swf DEBUG: pageUrl : http://www.ceskatelevize.cz/porady/10266819072-vypravej/ve-stopach-doby/197… DEBUG: app : CTv-video DEBUG: flashVer : WIN 10,3,183,11 DEBUG: live : no DEBUG: timeout : 30 sec DEBUG: SWFSHA256: DEBUG: 00 b9 3c 04 ba dd 2f 40 05 74 be 1b cb 7f c5 cd DEBUG: 1b ed 8c f9 1c ae 54 be f4 bd 07 a3 48 29 6c f4 DEBUG: SWFSize : 105686 DEBUG: Setting buffer time to: 36000000ms Connecting ... DEBUG: RTMP_Connect1, ... connected, handshaking DEBUG: HandShake: Client type: 03 DEBUG: HandShake: Client digest offset: 53 DEBUG: HandShake: Initial client digest: DEBUG: 5f 45 64 8c f0 16 f8 a6 23 99 f0 e9 d8 6e 8d 61 DEBUG: 10 d7 bf 45 0a 70 60 f1 f3 20 b4 46 de e2 44 e1 ERROR: RTMP_Connect1, handshake failed. DEBUG: Closing connection. I am not certain whether this means the handshake failed after the application of the secure token or before it. The packet capture of the webbrowser playing the beginning of the movie is here: http://tmp.pepak.net/ct.zip (the interesting packets, at least interesting to my eyes, are 1062 and 1078) Thanks for any tips as to where to look. Pepak

3 8