Protocol scope and method
RTP timestamps are media-clock units, not Unix time. Select the payload clock rate used by the stream.
deltaMs = timestampDelta / clockRate × 1000.
Diagnostic scenario
Collect adjacent RTP timestamps from one SSRC and enter the clock rate negotiated for that payload. Compare calculated spacing with the expected video frame or audio packet cadence, while noting marker boundaries and any timestamp reuse across fragmented media units.
How to interpret the result
RTP timestamps are media-clock samples, not wall-clock dates. Multiple packets can legitimately share a timestamp for one frame, and wraparound is expected. A wrong clock-rate assumption scales every millisecond result while preserving apparently regular spacing.
Input reference
- RTP timestamps
- Example default: Sample input included
- Clock rate (Hz)
- Example default: 90000
Common mistakes
- Using an unredacted production capture with vehicle, credential or network identifiers.
- Using Unix-time or a default 90 kHz clock for every payload.
- Treating a successfully parsed sample as standards compliance or interoperability proof.
Before using the result
- Confirm the protocol edition, transport framing and vendor profile before interpreting fields.
- Confirm clock rate and timestamp grouping from negotiated media data.
- Keep a redacted known-good and known-bad sample as a regression pair.
Questions to check during diagnosis
Does the RTP Timestamp Delta Analyzer leave my browser?
No application upload is used. Avoid putting sensitive production data in shareable URLs.
Is this a standards compliance test?
No. Confirm the edition and vendor profile with licensed documents and your target platform.
Offline diagnostic aid. Verify fields, version and vendor extensions before production use.