[rtmpdump] Junk CTS Timestamps from C-SPAN1? Did fix in mplayer, but rtmpdump?
gunnar at surfnet.fi
Wed Dec 4 19:10:17 CET 2013
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)
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?
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.
More information about the rtmpdump