[rtmpdump] Experimental patch to automatically disable BUFX

[Ulrik Dickow]

Den 14-08-2012 09:27, Howard Chu skrev:
> Yes, an RTMP server can only seek to the nearest keyframe boundary. It would
> make most sense to not disable the BUFX hack. Instead, just filter out old
> frames after doing the pause/resume.

No, that's only an improvement if we get lots of data between the seeks,
and the backwards jump is much smaller than the previous batch
downloaded.  Fine in theory, but in practice we can backtrack way too
much & often with BUFX enabled.

The "filtering with BUFX enabled" method will take the same time as
current rtmpdump without -R.  The improvement will then "only" be that
you actually get a usable file afterwards.  But with -R or
auto-disabling the download will be much faster.  At least for the
server I originally tested:

   150s to download 118s with BUFX enabled (many backwards jumps)

    41s to download 99s with BUFX disabled (-R, no jumps at all)

I.e. the filtering method (without auto-disable) is slower than real-time!

I noticed all the jump points for the 2m 30s session (this was before I
implemented -R):

   $ date; rtmpdump ... --start 704 --stop 822 ...; date
   fre jul 20 10:48:52 CEST 2012
   RTMPDump v2.4
   [... only showing the %-lines left-over after jumps her...]
   1405.347 kB / 711.94 sec (38.2%)
   5555.633 kB / 727.94 sec (39.1%)
   10986.543 kB / 743.78 sec (39.9%)
   13461.868 kB / 734.06 sec (39.4%)
   16343.396 kB / 742.46 sec (39.9%)
   20197.223 kB / 757.10 sec (40.7%)
   24174.977 kB / 764.38 sec (41.0%)
   28213.186 kB / 772.05 sec (41.5%)
   32211.726 kB / 779.10 sec (41.8%)
   36330.492 kB / 787.58 sec (42.3%)
   40266.707 kB / 794.62 sec (42.7%)
   42913.987 kB / 794.46 sec (42.7%)
   48312.022 kB / 817.86 sec (43.9%)
   52374.223 kB / 818.06 sec (43.9%)
   55852.532 kB / 822.87 sec (44.2%)
   Download may be incomplete (downloaded about 44.20%), try resuming
   fre jul 20 10:51:22 CEST 2012

The times are where you jump _from_.  It jumps to an earlier time.  As
you see, this method is very wasteful of time and bandwidth.

- Ulrik