pcapreport1
Get info about a ts in a pcap
Usage
pcapinfo {-h | -help
[detail]}
pcapinfo [-err
stdout]
[-err
stderr]
[{-verbose | -v}]
[{-name
base_name | -n
base_name}]
[{-extract | -x}]
[{-csvgen | -c}]
[{-output
udp_name | -o
udp_name}]
[{-max
max_read | -m
max_read}]
[-data]
[-a]
[-d
dest_ip
[:port]]
[{-g | -good-ts-only}]
[-keep-bad]
[-tfmt
time_format]
[{-dump-data | -D}]
[{-extra-dump | -E}]
[{-times | -t}]
[{-skew-discontinuity-threshold
threshold | -skew
threshold}]
file
Overview
Report and/or extract the Transport Streams in a .pcap. In analyse mode ( -a ) the timing info in the TS (PCRs) can be compared with the timing info in the pcap.
-
-h, -help -
Produce usage summary
-
-h detail, -help detail -
Produce usage + more detail on what the output actually means
-
-a, -analyse -
Analyse. Produces summary info on every TS in the pcap
-
-d dest_ip[:port], -destip dest_ip[:port] -
Select data with the given destination IP and port. If the port is not specified, it defaults to 0 (see below).
-
-g, -good-ts-only -
Only extract/analyse packets that seem entirely good. By default there is a bit of slack in determining if a packet is good and some dodgy packets are let through. This switch ensures that all packets pass simple testing
-
-keep-bad -
Extract all packets including bad ones. Is implied if an ip & port filter is set. Overridden by
--good-ts-only. -
-tfmt time_format -
Sets the format for printed times
time_format is one of
90-
[Default] show as 90KHz timestamps (suffix 't' on the values: e.g., 4362599t).
27-
Show as 27MHz timestamps (similar, e.g., 25151:000t).
32-
Show as 90KHz timestamps, but only the low 32 bits.
ms-
Show as milliseconds.
hms-
Show as hours/minutes/seconds (H:MM:SS.ssss, the H can be more than one digit if necessary)
-
-dump-data, -D -
Dump any data in the input file to stdout.
-
-extra-dump, -E -
Dump only data which isn't being sent to the Fl o file.
-
-times, -t -
Report continuously on PCR vs PCAP timing for the destination specified in
-d. -
-skew-discontinuity-threshold threshold, -skew threshold -
Gives the skew discontinuity threshold in 90kHz units. A value of 0 disables this. [default = 6*90000]
-
-split-section -
Split extracted streams into multiple files on section (discontinutity) boundaries
-
-err stdout -
Write error messages to standard output (the default)
-
-err stderr -
Write error messages to standard error (Unix traditional)
-
-v, -verbose -
Output extra information about packets
- file
-
The pcap stream file to get info on
Specifying 0.0.0.0 for destination IP will capture all hosts, specifying 0 as a destination port will capture all ports on the destination host.
Network packet numbers start at 1 (like wireshark)
TS packet numbers start at 0.
Analyse output
- Times
-
(packet and PCR) The times associated with packets and PCR are held internally in 90kHz units and are displayed in those units by default
- Stream
-
A set of packets to the same IP & Port. TS streams are detected by looking for 0x47s at appropriate places in the packets
- Section
-
A part of a stream which appears to have a continuous TS embedded in it. If the PCR jumps then a new section should be started (though this will not generate a separate .ts file if the extraction option is in effect unless
-split-sectionis specified, nor will it generate a new .csv file.)As it stands pcapreport will only report on a single PCR pid within a TS. If multiple pids with PCRs are detected then this will be reported but the other PCRs will be ignored
- Skew
-
This is the difference between the time in the pcap for a UDP packet and any PCR found in the TS contained within that packet. The accuracy of this figure obviously depends on how good the clock was in the capture process. Skew is arbitrarily set to zero at the start of a section. A skew of >6s is assumed to be a discontinuity and will start a new section.
Positive skew means that we received too low a PCR for this timestamp.
- Drift
-
This is skew over time and (assuming that the playout process is good) represents the difference in speed between the transmitters clock and the receivers clock. The algorithm for determining this isn't very sophisticated so if you have a large maximum jitter or a short sample this should be taken with a pinch of salt. Beware also that PC clocks (like the one in the m/c doing the tcpdump) are not always amongst the most stable or accurate; however they should be good enough to detect gross errors
- Jitter
-
This is measured as the difference between the maximum and minimum skews over a 10sec (max 1024 samples) period. This should be long enough to capture a good baseline but short enough that drift has a negligible effect
- Max Jitter
-
The maximum value of jitter (see above) found in a section
Releases
8 releases since Debian 6.0 (Squeeze); the text changed 1 time.
-E since Debian 11 (Bullseye);
-a since Debian 11 (Bullseye);
-analyse since Debian 11 (Bullseye);
-d since Debian 11 (Bullseye);
-destip since Debian 11 (Bullseye);
-dump-data since Debian 11 (Bullseye);
-err since Debian 11 (Bullseye);
-extra-dump since Debian 11 (Bullseye);
-g since Debian 11 (Bullseye);
-good-ts-only since Debian 11 (Bullseye);
-h since Debian 11 (Bullseye);
-help since Debian 11 (Bullseye);
-keep-bad since Debian 11 (Bullseye);
-skew since Debian 11 (Bullseye);
-skew-discontinuity-threshold since Debian 11 (Bullseye);
-split-section since Debian 11 (Bullseye);
-tfmt since Debian 11 (Bullseye);
-times since Debian 11 (Bullseye);
-verbose since Debian 11 (Bullseye).
--dump-data until Debian 10 (Buster);
--extra-dump until Debian 10 (Buster);
--skew-discontinuity-threshold until Debian 10 (Buster);
--times until Debian 10 (Buster);
--verbose until Debian 10 (Buster);
-e until Debian 10 (Buster).