On 07-08-2012 22:26, Gunnar wrote:

OK, disabling the BUFX-hack, --R is now implemented, great!

You're welcome :) (-R).

Before I start trying more tricks on my own, what about, and has-or-is anyone else working on something like this

Yes, a little bit.

-- it seems possible to detect this jmp-backwards from the EOF received ctrl packet

Didn't look at that, but...

(better than comparing time stamps,etc "on the fly"?)

Perhaps. A first good shot at comparing time stamps on the fly was published to the mailing list on May 4 2012 by Jindřich Makovička: http://lists.mplayerhq.hu/pipermail/rtmpdump/2012-May/001947.html It still applies cleanly to master. I repost his patch here as my first attachment (PATCH 1/2), because my extended patch in the second attachment (PATCH 2/2) elaborates on the idea. See the long log comment in patch 2.

-- minimum "fix", at least exit rtmpdump with error-bells screaming, user can then manually add the -R switch

As you can see in attachment 3, the combined patches 1+2 (= git2) fixes the problem perfectly with the CSPAN server, giving bit-identical results of current master with -R versus git2 version without -R (automatically disabling BUFX as needed) This experimental version also gives perfect, bit-identical result with the server that I originally implemented -R for (with -A 713 -B 813, no longer needing -R). Thus we shouldn't need to scream at all until we find a server where the output is not perfect -- or if the time wasted on BUFX auto-disabling is more than the handful of seconds presently observed (at most). I _do_ scream a bit more than needed, perhaps, in the current patch, emitting a single WARNING line that often gets buried among INFO-lines. If you want to warn users more loudly that the download was not 100% safe/optimal, you could add a few lines in rtmpdump.c to detect that the library disabled the BUFX flag during download, and then as a final output line recommend that -R is used explicitly for future downloads from this server.

-- automatic restart after detection with BUFXHack disabled

Sort of. Patch 1+2 just let the packets flow by by themselves, dropping the ones that are "too old" for the output, hoping that we hit exactly the right frame again later on (and INFO-logging the successful hits for these audio+video packets).

(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)

Probably much easier now with the present rtmpdump master to try that again if you think the timestamp-skipping method is too risky or ugly.

But it seems that at that point this "jump-back-problem" can be "totally fixed"

Right. Full fix requires that librtmpdump safely detects and corrects the problem. The attached patches are not 100% safe, but as mentioned earlier, at least I've seen the combined patch work 100% correctly at two different servers. Since the attached test session is somewhat large, I'll point to the last test as the most interesting one, essentially this: $ .../rtmpdump -r rtmp://video.c-spanarchives.org/bwcheck -y mp4:downloads/305/305813-2/305813-2-MP4-STD/305813-2-MP4-STD_01.mp4 -A 1800 -B 2100 -o cspan-1800_2100_git2.flv RTMPDump v2.4-37-g6664a87 [...] INFO: duration 3467.61 INFO: Timestamp jumped from 1807985 ms to 1800006 ms. Disabling BUFX hack and catching up. WARNING: Timestamp jumped from 1807959 ms to 1800042 ms (BUFX hack no longer enabled). INFO: Successfully hit ts = 1807959 ms again (skipped, prev = 1807917 ms) INFO: Successfully hit ts = 1807985 ms again (skipped, prev = 1807963 ms) 15871.687 kB / 2101.51 sec (60.6%) resulting in a flv file with same sha256sum as with current master with -R, and only spending 2-3 seconds more on the download due to the backwards jump. Regards, Ulrik Dickow