[rtmpdump] Junk CTS Timestamps from C-SPAN1?(almost dupl message)
gunnar.holm at surfnet.fi
Thu Dec 5 15:33:58 CET 2013
Almost duplicate message, thought first one had gone wrong, can be
Anyway, the difference that I also managed to use a brute force fix on
rtmpdump, managed to add a "sanity check" on the 24 bit (cmposition
timestamp" in Read_1_Packet by using, the commented out (#if 0) old code.
Checks if CTS < 10000 as an unsigned int, if not sets it to 32.
HOWEVER, tried to print out, check "where it comes from" when loaded
into the packet buffer but difficult to find "it" in the code.
My best try logs only nice "valid" timestamps which would mean something
is overwriting, changing it somewhere "along the way".
However downloaded latest "official" windows rtmpdump.exe and it also
Additionally the magic of "only on CSPAN1" and "started a month ago"
althgh one psbl oservation is that when started the CSPAN1 files have a
very long delay between audio and video for mplayer to correct for?
Could cause ovf of buffers or similar in rtmpdmp?
Question: Where would be earliest time, code place where I can easily
check the timestamp, as close to reading sockets as possible?
(I have yet to figure out how exactly this ReadN and buffering, decoding
socket data is done, TCP, rtmp and video packet mess, not to forget
timestamps here and there? plus resume code)
PS The junk-stamps occure maybe every 2-3 second, fairly regularly in
1-2 bursts, values always "similar" in the same stream, file.
PPS have not tested on ubuntu yet, everything on windows
More information about the rtmpdump