August 2012 - rtmpdump - lists.mplayerhq.hu

Handshake 10
by Steven Penny 05 Sep '12

05 Sep '12

As discussed with compn, this is the unofficial Handshake 10 patch. I in no way endorse this patch or intend to provide builds for it. I am merely posting it for historical purpose, and because GitHub will not host it.

1 1

Experimental patch to automatically disable BUFX
by Gunnar 14 Aug '12

14 Aug '12

ref*Ulrik Dickow* * log* > 150s to download 118s with BUFX enabled (many backwards jumps) > 41s to download 99s with BUFX disabled (-R, no jumps at all) 41s for 99s file seems according to "old rule of thumb" of getting 2x speed "at full speed". I assume the servers are-were set up for 2x "bursts" by simply limiting max feed to 2x? However, most CSPAN servers and other "BBC-like" can do, and do, 4-8x speed (with the BUFX hack), have been doing that for some years. Without jumpbacks it means one gets a 100s clip in 25 or less seconds Also seems most servers (like CSPAN) now are starting with some higher initial Nx speed-max "to fill buffers" but then slow down to more nominal. Anyway, my point is that with CSPAN, without -R, ie with jumpbacks, I get a file which can be 2-3x in SIZE!! I assume that is also (at least) the amount of (excessive) traffic. Goes somewhat well with my observation that I get a jump-back of appr 2.75/2s every 4x5.5s (with server willing to do maybe 4x). Often even longer, repeated jump-backs, jump-jump-jump-backs I.m fairly sure I have observed (and watched videos with) "multiple jump-backs inside each other". But that is probably because the BUFX hack "remembers a timestamp" from an already jumped-back videochunk"> That is, the "odd" things I observed by following only the EOFs and 20k-packets with BUFX enabled. It looked like BUFX first "asked" for the actual latest timestamp (but got an earlier) and then, often very soon, "in pairs",for an even earlier timestamp. ANyway, my point that the amount of "excessive traffic" can be very high, although in theory only..hmm.. 2.75/2s every 5.5s? 25%? But additionally - a 2x speed seems "OK" for the (old)servers. - more than that probably only uses, or abuses, this (new?) "intro-super-speed" to fill buffers. It seems possible that abusing this 4-8x intro-speed wld start a "rtmpdump-war" from the "server-people" That is, I would suggest some kind of "semi-friendly" function, "adaptive Nx speed", where N is max 2-3? (this started from the server becoming "adaptive" or "predicting") PS Note, for one (automated, looped) rtmpdump version I did not close the stream, connection, session properly (stopped, next one, when I found out, from the meta data, that I alrdy had the video). My IP number got blacklisted after some "automated nights"! (the local "BBC"). That is, I started some 100 or more streams, but left most "hanging", non-properly closed after only some 2-4 seconds

1 0

Experimental patch to automatically disable BUFX
by Gunnar 14 Aug '12

14 Aug '12

Thanks, not yet time to check your patches, but some quick observations I made in regards to the CSPAN server and stream. EOF good as trigger, 20k mastodont packets 2.75s apart, keyframes?, stream feed always returns, jumps "backwards" to earlier, latest one. --- Triggered debugging using the EOF ctrl message from CSPAN, seemed to work very well I checked with wiresshark too, easy to search for "pause", found in notify and unpause,etc as ASCII Checked actual last timestamp before the EOF and the ones used by rtmpdump to restart stream, and first arrived after restart. Some odd behavior, but then noticed the restarted feed continues, or "backwards-jumps" to "nice decimal numbers". Additionally a nearby 'mastodont packet" (npacketlenght? somewhere in rtmp.c). OK set a print-test for more than 10K, looked good, then 20k, PERFECT!! Catches only these 2.75s packets. FInal observation-result. - Not sure, not dble-chked, but CSPAN-server seems to want 5.5s buffer - every 2.75s, a "huge mastodont rtmp-packet" (have not digged deeper, video keyframe probably??) - Most important, after the restart of the stream the feed always starts from the earlier latest "20k mastodont packet" That is, typical behavior - CSPAN server does notify/pause, EOF at some random point (obv after a 20k-packet) - after BUFX-restart the stream-feed starts from the earliest "already streamed" 20k-packet (keyframe?) Nice timestamps like in your log,the 1800,000 + 6ms 1807985 ms to 1800006 ms" when accounting for the "small milliseconds", 6ms, closest timestamp to that exact N x 2.750s PS Additional observation, I am getting these EOFs appr every 4-8th 2.75s (mastodont packet). Maybe 2.75s or 5.5s also is some kind of quarter or half buffering size?? Wld make sense togther with keyframe interval, This when streaming speed was appr 300kB/s, compared to nominal, hmm.. 60-80kB/s? (with some CSPAN servers and sometimes, I actually get upto 800kB/s although"far away") Gunnar

3 3

Experimental patch to automatically disable BUFX
by Gunnar 14 Aug '12

14 Aug '12

Ouch, one need to always remember one is "abusing" that poor server... Messing up stream-capacity for ordinary users.. Gunnar

1 0

Re: [rtmpdump] another verifiable "video jumps-backwards" case
by Gunnar 13 Aug '12

13 Aug '12

(forgot emailadr of forum, never used this bfr) On 8/7/2012 2:40 AM, Steven Penny wrote: OK, disabling the BUFX-hack, --R is now implemented, great! Before I start trying more tricks on my own, what about, and has-or-is anyone else working on something like this -- it seems possible to detect this jmp-backwards from the EOF received ctrl packet (better than comparing time stamps,etc "on the fly"?) -- minimum "fix", at least exit rtmpdump with error-bells screaming, user can then manually add the -R switch -- automatic restart after detection with BUFXHack disabled (demands lots of re-inits of variables, pointers,flags,etc?) (changed one old non-lib rtmpdump to be able to loop through many downloads, got messy, always something "wrong' in specific situations) But it seems that at that point this "jump-back-problem" can be "totally fixed" Gunnar > You need to keep up with the times. >

2 1

GitHub situation
by Steven Penny 12 Aug '12

12 Aug '12

GitHub situation Forgive if this is off topic. For those who dont know me, I maintain the official Windows builds for RtmpDump. I also host the RtmpDump mirror on GitHub, svnpenn/rtmpdump. I am also a senior member on the stream-recorder forum, with hundreds of posts logged. Xeebo <xeebosoft(a)ukr.net> has filed DMCA notice and the GitHub repo is now down for 10 days. I made a thread on stream-recorder about this situation. My account on stream-recorder was banned and my thread removed, with no explanation by PM or email. I would like my build pulled from the RtmpDump site, it is clear that my contributions are no longer appreciated. http://rtmpdump.mplayerhq.hu/download/rtmpdump-v2.4-35-ge0056c5-master.7z

4 6

branch master updated. c61a7a3 remove svnpenn builds from site
by gil＠avcodec.org 12 Aug '12

12 Aug '12

The branch, master has been updated via c61a7a3114b9eaf1453c1d4cd912b6b41ec16ab4 (commit) from 00171410105a6de7cadbefef64f58d50d7ffd087 (commit) - Log ----------------------------------------------------------------- commit c61a7a3114b9eaf1453c1d4cd912b6b41ec16ab4 Author: Compn <tempn(a)twmi.rr.com> AuthorDate: Sat Aug 11 23:23:24 2012 -0400 Commit: Compn <tempn(a)twmi.rr.com> CommitDate: Sat Aug 11 23:23:24 2012 -0400 remove svnpenn builds from site diff --git a/index.html b/index.html index 9c61d5d..8ed32b9 100644 --- a/index.html +++ b/index.html @@ -96,7 +96,7 @@ relaying the data from the server to the client. <p> 2010-06-30: Download source tarball <a href="download/rtmpdump-2.3.tgz">rtmpdump-2.3.tgz</a> <br> -2012-08-01: Download Windows build <a href="download/rtmpdump-v2.4-35-ge0056c5-master.7z">rtmpdump-v2.4-35-ge0056c5-master.7z</a> +2012-08-11: Download Windows build unavailable, builds welcome. <br> 2010-06-30: Download Android build <a href="download/rtmpdump-2.3-android.zip">rtmpdump-2.3-android.zip</a> <br> ----------------------------------------------------------------------- Summary of changes: index.html | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive --

1 0

missing windows libs
by Roger Pack 09 Aug '12

09 Aug '12

As a note, at least with 2.3, when I try and link against a static library, I find that I'm missing the following libraries: -lws2_32 -lwinmm -lgdi32 perhaps they should be added to the librtmp.pc file when cross compiling for windows? Thank you. -r

1 0

another verifiable "video jumps-backwards" case
by Gunnar 07 Aug '12

07 Aug '12

Symptom (windows, on V 2.4, also 2.3) Console %-counter goes to, lets say 0.8%, back to 0.2%, goes to 0.9%, back to 0.4%, etc. At every discontinuity a new "info page" of the video is printed Stored video also "jumps backwards", repeats in the same way, file becomes much larger than expected. Using -V for more info seem to show it is connected to the stream.pause.notify and unpause, send-pause interchange with server? This eventually causes a "Stream EOF 1" message, and new attempt? but jumps backwards? In an earlier case I "butchered" the (V2.3) code, commented out the send-pause code in rtmpdump, "fixed" the problem but the download speed of course dropped to "nominal",etc side effects. the full rtmpdump argument line rtmpdump -V -r "rtmp://video.c-spanarchives.org:1935/bwcheck" -a "bwcheck" -f "WIN 11,3,300,270" -W "http://www.c-spanvideo.org/videoLibrary/assets/swf/CSPANPlayer.swf?ver=12.3…" -p "http://www.c-spanvideo.org/program/TaxPolicyR" -y "mp4:downloads/305/305813-2/305813-2-MP4-STD/305813-2-MP4-STD_01.mp4" -o 305813-2-MP4-STD_01test.flv minimal argument line rtmpdump -V -r "rtmp://video.c-spanarchives.org:1935/bwcheck" -a "bwcheck" -y "mp4:downloads/305/305813-2/305813-2-MP4-STD/305813-2-MP4-STD_01.mp4" -o test.flv http://c-span.org is not any "flash-by-night" streamer, but THE MAJOR ONE, have 30 years 24/7 archived of US congressional sessions , hearings,etc,etc probably "largest in world", 100,000s hours of "professional streams". However, they use different servers for different archived material, some clearly outsourced This problem seems to be connected to some recent upgrade on this specific stream-server service. That is, recently new server sw-versions on c-spanarchives and maybe that new app bwcheck, never seen it before. Gunnar

2 1

rtmpdump 2.4: bails at the 4 GB mark?
by Chris Cullen 02 Aug '12

02 Aug '12

I think is might also be related to the fact the the resume feature seems to be non-functional. Canceling a stream, any size as far as i can tell, and then trying to resume it produces the same errors as going over 4GB. In Short: WARNING: Stream does not start with requested frame, ignoring data... I'll attach a full debug

1 0