Experimental patch to automatically disable BUFX
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
Gunnar wrote:
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"
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.
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
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.
participants (3)
-
Gunnar -
Howard Chu -
Ulrik Dickow