A week ago CSPAN1 Live started to "chop and stop" when recorded with rtmpdump and played back with mplayer. CSPAN2,3 and their other live channels,streams work OK (as before) http://www.c-span.org/Live-Video/C-SPAN/ rtmp://cp82346.live.edgefcs.net:1935/live and CSPAN1@14845 the Video TImestamp in MPlayer jumps a typical "junk-jump", tens or hundreds of seconds backwards or forwards. Mplayer tries to track, as stopping video, but continues for a while when user steps it a little forward (resets timestamps) Quick brute force fix in mplayer to test the 24 bit CTS (Composition Time Stamp) for "sanity" and zero or set it to something "normal". Usually toggles 30-32 and clear junk-jumps a cple or more seconds apart. It seems Adobe flashplayer does some similar sanity check as it at least does not totally stop the video or then rtmpdump "is at fault". Started to look into - similar brute force sanity check or other solution in rtmpdump, then file cld be played with "normal" mplayers. (- special tool to scan the file and correct the junk-jumps) However, got some google hits on others having similar problem and I'm not really sure abt "all these timestamps and rtmpdump code" Any idea, advice or even some old fix, patch? Gunnar PS Even found some old (pre-library?) code in rtmpdump (rtmp.c Read_1_Packet() appr line 4180) which seemed to "zero the (composition or delta?) timestamp although no sanity-check? But not sure on these Absolute Timestamps and "delta or composition" stamps? Who does what and where does it go?