[bugmenotfree]

Hello to everyone on the forum.
I applied the patch attached
http://lists.mplayerhq.hu/pipermail/rtmpdump/attachments/20110908/2a239630/attachment.bin
in this message in the rtmpdump mailing list
http://lists.mplayerhq.hu/pipermail/rtmpdump/2011-September/001578.html
on the latest Git version and compiled rtmpdump in Windows for downloading the Daily Show stream on the Comedy Central website.

It does not work while my compiled version of the latest Git does but the download stops at about 15-20% of the file. Resuming works so I can download the whole file if I run rtmpdump 6-7 times but the file is sometimes corrupted (small skips presumably at the points rtmpdump resumes the download).

After comparing all the latest (2011-08-12) Git source with and without the patch applied the only difference was a line in "rtmp.c"
if (packet->m_nBodySize > 2 && packet->m_body[2] > 0x01)
that was changed to
if (packet->m_nBodySize > 2 && packet->m_body[2] > 0x02)

Is the above correct, does the patch only change one number in the RTMPdump (http://all-streaming-media.com/record-video-stream/rtmpdump-freeware-console-RTMP-downloading-application.htm) source?

[AmazingMatze]

Hello,

you need the "rtmpdump_swfverficiation_fallback.patch".

Have a look here:
http://lists.mplayerhq.hu/pipermail/rtmpdump/2011-September/001581.html

You can download the patch in this thread:
http://web.archiveorange.com/archive/v/5hTZaohTQOPdWMEHNd8q

[bugmenotfree]

Thanks
I missed the second patch.
I applied it as well and again rtmpdump does not even start the download with error:

ERROR: RTMP_ReadPacket, failed to read RTMP packet header
verbose
rtmpdump --flv "ds_16119_act1_768x432_1720.mp4" --resume --rtmp "rtmpe://cp9950.edgefcs.net/ondemand/mtvnorigi
n/gsp.comedystor/com/dailyshow/TDS/season_16/episode_119/ds_16119_act1_768x432_1720.mp4" --swfVfy "htt
p://media.mtvnservices.com/player/prime/mediaplayerprime.1.9.2.swf" --verbose
RTMPDump 2.4 git-c58cfb3 2011-8-12
(c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL
DEBUG: Protocol : RTMPE
DEBUG: Hostname : cp9950.edgefcs.net
DEBUG: Port : 1935
DEBUG: Playpath : mp4:mtvnorigin/gsp.comedystor/com/dailyshow/TDS/season_16/episode_119/ds_16119_act1_768x43
2_1720
DEBUG: tcUrl : rtmpe://cp9950.edgefcs.net:1935/ondemand
DEBUG: swfUrl : http://media.mtvnservices.com/player/prime/mediaplayerprime.1.9.2.swf
DEBUG: app : ondemand
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: 166
DEBUG: HandShake: Client digest offset: 879
DEBUG: HandShake: Initial client digest:
DEBUG: 9c eb 90 68 0c fe ee d9 6f 8d d9 a6 6a 0c 2a 0f
DEBUG: 23 5a 75 3c 47 70 f4 f9 a1 ea ce 6c cd 6f d2 a7
DEBUG: HandShake: Type Answer : 09
WARNING: HandShake: Type mismatch: client sent 6, server answered 9
DEBUG: HandShake: Server Uptime : 1197967947
DEBUG: HandShake: FMS Version : 3.5.7.1
DEBUG: HandShake: Server DH public key offset: 528
DEBUG: HandShake: Secret key:
DEBUG: 85 a3 ac 77 16 62 88 31 11 78 1e 13 31 3e 34 cb
DEBUG: 57 38 f1 8b 87 b9 94 bd d4 46 a0 a9 db 54 af ae
DEBUG: e8 64 09 9f 59 cf 10 f2 5c 26 17 4d 0f 5e fe 3c
DEBUG: 77 28 86 23 28 a0 2a 18 b3 fc ec 55 32 51 a6 9b
DEBUG: 1f 20 c9 2b 46 2e 17 f8 73 df 1b ec 96 86 71 3b
DEBUG: 53 3f da 1e 50 9a f4 17 ea 37 9f 6b bd 6f 9e bb
DEBUG: 35 0b 55 67 66 e4 90 9f 94 89 1d f5 cd 26 3c ef
DEBUG: 79 76 d4 0a 87 a6 18 51 95 d6 d7 2c d1 19 4a 38
DEBUG: RC4 Out Key:
DEBUG: 3c 06 e4 ac c4 9e 7f 4f 85 a3 5f 99 d3 78 23 f8
DEBUG: RC4 In Key:
DEBUG: ec 99 58 84 3a d8 f9 c0 be 09 21 c0 f9 24 e6 7e
DEBUG: HandShake: Calculated digest key from secure key and server digest:
DEBUG: 76 8c 5c 5a 47 2f db 68 00 d6 f5 5e 5a c2 9c 2b
DEBUG: ad 3e 27 42 e1 bd 35 8f eb 60 02 92 e4 3d 23 88
DEBUG: HandShake: Client signature calculated:
DEBUG: 99 a4 db 3f 76 8e 27 e1 dc 3e 10 30 f3 e8 7b 6b
DEBUG: 20 b5 58 3b 53 b1 7a 9e 01 82 cf f4 b7 f8 7c dd
DEBUG: HandShake: Server sent signature:
DEBUG: ac 34 f4 12 04 64 d8 1a f0 98 17 93 66 db e7 92
DEBUG: d8 e5 1b 68 8d b6 1d 2b 7c 11 fc 85 6f 66 80 72
DEBUG: HandShake: Digest key:
DEBUG: 19 7c 47 bf e3 19 ed 01 23 fb a6 af d0 50 bb 58
DEBUG: 20 56 01 30 6d 03 2b bd 00 11 00 ff 15 74 73 72
DEBUG: HandShake: Signature calculated:
DEBUG: ac 34 f4 12 04 64 d8 1a f0 98 17 93 66 db e7 92
DEBUG: d8 e5 1b 68 8d b6 1d 2b 7c 11 fc 85 6f 66 80 72
DEBUG: HandShake: Genuine Adobe Flash Media Server
DEBUG: HandShake: Handshaking finished....
DEBUG: RTMP_Connect1, handshaked
DEBUG: Invoking connect
INFO: Connected...
DEBUG: HandleServerBW: server BW = 1250000
DEBUG: HandleClientBW: client BW = 1250000 2
DEBUG: HandleCtrl, received ctrl. type: 26, len: 3
DEBUG: HandleCtrl, SWFVerification ping received:
ERROR: HandleCtrl: SWFVerification Type 2 request not supported, attempting to use SWFVerification Type 1! P
atches welcome...
DEBUG: sending ctrl. type: 0x001b
DEBUG: Sending SWFVerification response:
DEBUG: 00 1b 01 01 00 1e db f0 00 1e db f0 be 41 f9 5a
DEBUG: bd 0f 20 ed 13 90 c4 97 25 7e f5 e6 b1 a2 dd 06
DEBUG: 14 06 74 b4 75 52 db 0b 76 2e b1 7c
DEBUG: RTMP_ClientPacket, received: invoke 242 bytes
DEBUG: (object begin)
DEBUG: (object begin)
DEBUG: Property: <Name: fmsVer, STRING: FMS/3,5,7,7009>
DEBUG: Property: <Name: capabilities, NUMBER: 127.00>
DEBUG: Property: <Name: mode, NUMBER: 1.00>
DEBUG: (object end)
DEBUG: (object begin)
DEBUG: Property: <Name: level, STRING: status>
DEBUG: Property: <Name: code, STRING: NetConnection.Connect.Success>
DEBUG: Property: <Name: description, STRING: Connection succeeded.>
DEBUG: Property: <Name: objectEncoding, NUMBER: 0.00>
DEBUG: Property: <Name: data, OBJECT>
DEBUG: (object begin)
DEBUG: Property: <Name: version, STRING: 3,5,7,7009>
DEBUG: (object end)
DEBUG: (object end)
DEBUG: (object end)
DEBUG: HandleInvoke, server invoking <_result>
DEBUG: HandleInvoke, received result for method call <connect>
DEBUG: sending ctrl. type: 0x0003
DEBUG: Invoking createStream
DEBUG: RTMP_ClientPacket, received: invoke 21 bytes
DEBUG: (object begin)
DEBUG: Property: NULL
DEBUG: (object end)
DEBUG: HandleInvoke, server invoking <onBWDone>
DEBUG: Invoking _checkbw
ERROR: RTMP_ReadPacket, failed to read RTMP packet header
DEBUG: Closing connection.

[AmazingMatze]

I guess this is the correct URL for your specific episode:
hXXp://www.thedailyshow.com/full-episodes/wed-september-21-2011-mitch-daniels

At the moment only the server "viacomccstrmfs.fplive.net" needs the patched version. You can test it with this command line (I had -no- download errors using this server):


rtmpdump -r "rtmpe://viacomccstrmfs.fplive.net/viacomccstrm/gsp.comedystor/com/dailyshow/TDS/season_16/episode_119/ds_16119_act1_768x432_1720.mp4" -W "http://media.mtvnservices.com/player/prime/mediaplayerprime.1.9.2.swf" -o "ds_16119_act1_768x432_1720.mp4"


As you can see, the show is splitted into "acts"... just replace "act1" with "act2" and so on to get the whole show :-)

If you want to use the server "cp9950.edgefcs.net" you don't need the patched version of RTMPdump (http://all-streaming-media.com/record-video-stream/rtmpdump-freeware-console-RTMP-downloading-application.htm) at all. The patched version even fails if you don't remove the "--swfVfy / -W" parameter... This command line worked with my patched version of RTMPDump (However I had the same download errors you spoke of):


rtmpdump -r "rtmpe://cp9950.edgefcs.net/ondemand/mtvnorigin/gsp.comedystor/com/dailyshow/TDS/season_16/episode_119/ds_16119_act1_768x432_1720.mp4" -e -o "ds_16119_act1_768x432_1720.mp4"


Btw, sniffing with wireshark while playing, only gave me the server "viacomccstrmfs.fplive.net"

[bugmenotfree]

Yes I got that after playing with the servers again but thanks for the help :) .
The reason I didn't try viacomccstrmfs.fplive.net to begin with was because it stopped to work a couple of months back for me with RTMPdump (http://all-streaming-media.com/record-video-stream/rtmpdump-freeware-console-RTMP-downloading-application.htm). I thought it was a geolocation thing or something and didn't think much of it, now they seem to only use that server for their videos with the website as confirmed by URLSnooper.
The acts to use are 1-4 for anyone interested, its the same every day. Sometimes when the interviews are posted in full on the webrtmpe://viacomccstrmfs.fplive.net/viacomccstrm/gsp.comedystor/com/dailyshow/TDS/season_16/episode_119/ds_16119_exclusive1_768x432_1720.mp4 is used with 1 going to 3 the highest they've ever done so far. Adding one to episode_119 and ds_16119 gives you the next episode 16 being the season and 119 the count of the episode on that season.
I will play around with this a bit more in a couple of days, and also try a couple of servers they used in the past and post whatever I come up with here. Judging from how little the code was changed to get very different results on the same servers, a version that can work on both is probably just a couple of tweaks away.
Do the developers read this forum or should I post on the mailing list?
And is this important enough to post there or am I splitting hairs?

[AmazingMatze]

Hmm. I can't see "very different results". Despite the errors I had downloading from the server "cp9950.edgefcs.net", the file was absolutely identical with the file I downloaded from the server "viacomccstrmfs.fplive.net". I used Windows file compare to verify that.
Yes, the developers do read the forum but I wouldn't bother them with that :)

[bugmenotfree]

Hmm. I can't see "very different results". Despite the errors I had downloading from the server "cp9950.edgefcs.net", the file was absolutely identical with the file I downloaded from the server "viacomccstrmfs.fplive.net". I used Windows file compare to verify that.
By very different results I mean that the regular version downloads only from cp9950.edgefcs.net and the patched only from viacomccstrmfs.fplive.net.
The files are identical.

Yes, the developers do read the forum but I wouldn't bother them with that :)
OK :)

[AmazingMatze]

By very different results I mean that the regular version downloads only from cp9950.edgefcs.net and the patched only from viacomccstrmfs.fplive.net.


No. The patched version works with -both- servers. As I said: you just have to remove the "--swfVfy / -W" parameter.

[bugmenotfree]

No. The patched version works with -both- servers. As I said: you just have to remove the "--swfVfy / -W" parameter.
I stand corrected it does.

And here to add to the confusion I found a server that from what I can tell works for both without problems (cp10740.edgefcs.net), the download finishes both times.
rtmpdump --flv "ds_16119_act1_768x432_1720.mp4" --resume --rtmp "rtmpe://cp10740.edgefcs.net/ondemand/mtvnorigin/gsp.comedystor/com/dailyshow/TDS/season_16/episode_119/ds_16119_act1_768x432_1720.mp4" --swfVfy "http://media.mtvnservices.com/player/prime/mediaplayerprime.1.9.2.swf"

[hulu_user]

Is this patch good for Hulu?

I used link below,
rtmpdump -r "rtmpe://hulufs.fplive.net:1935/hulu/491/14753491" -a "hulu/491/14753491" -f "LNX 11,0,1,152" -W "http://www.hulu.com/site-player/116946/playerwrapper.swf" -p "http://www.hulu.com/watch/61600/surface-episode-1-pilot#x-0,vepisode,1,0" -C Z: -y "mp4:agave14753491_4836598_H264_650.mp4" -o mp4_agave14753491_4836598_H264_650.flv -V

and got error like
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.

[KSV]

Is this patch good for Hulu?

it doesn't work on level3 hulu cdn but there are two other CDN's where Type 2 SWFVerification isn't used. you can use them to download videos from hulu.

[hulu_user]

KSV,

Thanks for reply. How to find out CDN list used by Hulu? Which one is not using SWFVerfication Type 2 yet? And how to redirect the request to those server?

[KSV]

Hulu encrypts their XML playlist. you can check the source code of Hulu.pm plugin of get-flash-videos or XBMC hulu plugin by bluecop to understand how it's retrieved and decrypted.

currently cp39466.edgefcs.net (Akamai) and hulu-xxx.fcod.llnwd.net (Limelight) CDN's doesn't use Type 2 SWFVerification. only hulufs.fplive.net (Level3) CDN uses Type 2 verification.