Skip to content

MISB ST 0804.4 requirement trace

This trace covers the checksum-pinned official 27 February 2014 publication, Real-Time Protocol for Motion Imagery and Metadata. The implementation is deliberately focused on the MPEG-2 Transport Stream over RTP profile selected by MISP-2019.1-76.

Requirement/area Implementation/test State
ST 0804.4-01, UDP transport application UDP socket plus transport.rtp datagrams Library produces and consumes UDP-ready datagrams; socket ownership is external
ST 0804.4-02, ST 0804.4-03, RTP/AVP RTPPacket, parse_rtp_packet RFC 3550 version-2 fixed header, CSRC, extension, padding, marker, sequence, timestamp, SSRC, and RFC 3551 static MP2T payload type verified
ST 0804.4-04, motion imagery and metadata client support RTP payload is passed unchanged to the existing program-aware TransportDemuxer and MetadataStreamDecoder Verified compositionally for multiplexed MPEG-2 TS carriage
ST 0804.4-18 / RFC 2250 §2, integral TS packets parse_rtp_mpeg2_transport, RTPMPEG2TransportPacketizer Exact 188-byte boundaries, TS sync, configured payload bound, and arbitrary input chunks verified
ST 0804.4-18 / RFC 2250 §2.1, MP2T RTP fields packetizer/parser/receiver Static payload type 33, caller-supplied 90 kHz timestamp, 16-bit sequence wrap, caller SSRC, marker on timestamp discontinuity, receiver reporting of unmarked backwards jumps, and normal timestamp wrap verified
RFC 3550 sequence observation RTPPacketReorderBuffer, RTPMPEG2TransportReceiver Count-bounded wrap-aware reordering, pressure/flush gap declarations, late/duplicate withholding, SSRC session locking, ordered demux composition, and a 20,000-packet wrap/loss/reorder/duplicate campaign with exact output and ceiling assertions verified
ST 0804.4-05, ST 0804.4-06, ST 0804.4-07, ST 0804.4-08, ST 0804.4-09, ST 0804.4-10, ST 0804.4-11, ST 0804.4-12, ST 0804.4-13, ST 0804.4-14, ST 0804.4-15, ST 0804.4-16, ST 0804.4-17, native elementary-stream RTP Not implemented; current scope is multiplexed MPEG-2 TS over RTP, so elementary H.262/AVC/KLV payload packetization and AVC SDP format parameters are explicit non-claims
ST 0804.4-19, ST 0804.4-20, RTCP synchronization and sender reports transport.rtcp, RTPMPEG2TransportPacketizer.compound_sender_report Strict generic framing; exact SR/RR/reception-block/SDES CNAME read/write; report-first and matching-CNAME compound validation; uint32 sender counters; rational wrap-safe RTP/NTP mapping; and separate video/metadata clock-alignment tests verified. Adaptive RTCP interval, membership, collision, and full session policy are not implemented
ST 0804.4-21, ST 0804.4-22, ST 0804.4-23, ST 0804.4-24, ST 0804.4-25, ST 0804.4-26, ST 0804.4-27, RTSP control Not implemented; socket lifecycle and interactive presentation control remain application/deployment concerns
ST 0804.4-28, SDP session description MPEG2TransportSessionDescription, parse_mpeg2_transport_sdp Dependency-free read/write for the implemented RTP/AVP MP2T profile, RFC 3551 payload type 33, 90 kHz rtpmap, IPv4/IPv6 unicast and multicast connection data, IPv4 TTL, bounded strict parsing, and lossless retention of an unmodified parsed description

The requirement inventory binds all 28 active identifiers to the acquired ST 0804.4 digest. The publication has no retired or deprecated requirement section. Inventory completeness does not turn the native-RTP or RTSP rows into implementation claims; those boundaries remain explicit above.

The packetizer deliberately requires the application to provide the RTP timestamp. RFC 2250 defines it as a 90 kHz value derived from the sender clock, synchronized to PCR, that represents the target transmission time of the first payload byte. A library running above the physical output scheduler cannot truthfully invent that value. The marker is set only when the caller declares a timestamp discontinuity; ordinary 32-bit timestamp wrap is accepted.

The receiver validates every RTP datagram before exposing its payload. Forward sequence gaps are accepted and reported because later TS packets can still be useful. A packet behind the expected sequence is reported and its payload is withheld. RTPPacketReorderBuffer can instead retain a caller-selected number of future packets before declaring a gap and releasing ordered packets.

When imagery and metadata are sent in separate RTP streams, ST 0804.4-19/-20 requires RTCP and Sender Reports. parse_rtcp_packets safely frames mixed RTCP packet types without discarding unknown payloads, while parse_rtcp_sender_reports decodes the paired NTP/RTP clocks and all reception report blocks. RTPNTPClockMapping converts timestamps with exact rational arithmetic and the RFC 3550 half-range rule for 32-bit RTP wrap. An NTP era must come from the surrounding session because it is not present in the wire value.

encode_rtcp_sender_compound and the MPEG-TS RTP packetizer generate the required SR-first compound packet with a matching SDES CNAME. Related media sessions should use the same stable participant CNAME. This remains a reusable synchronization and compound-codec core, not a complete RTCP session engine: applications still own adaptive transmission cadence, participant state, collision/BYE handling, socket allocation, and session timeout policy.