[rtmpdump] Experimental patch to automatically disable BUFX

[Howard Chu]

Ulrik Dickow wrote:
> 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.

It must still be highly server and encoding dependent. The hack was always
beneficial with Hulu and a variety of other servers on the Akamai network.