[rtmpdump] Junk CTS Timestamps from C-SPAN1? Did fix in mplayer, but rtmpdump?

[Gunnar]

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 at 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?

PPS Managed to use brute force on RTMPDUMP also, fund ne place to check 
CTS for sanity and replaced it with smething more normal.