Skip to content

webrtc: add RFC 7273 support

François Laignel requested to merge fengalin/gst-plugins-rs:webrtc-rfc7273 into main

Depends on:

Only the last commit is specific to this MR, the other commit implements other features which serve as a basis for this work and comes from the following MR:

  • !1463 (merged): this is the base infrastructure for the precise example MR stack. It aims at providing the same features & convenience as the RTSP based rtp-rapid-sync-example for WebRTC. It helped improve the WebRTC C stack with support for intra CNAME synchronization & RFC 6051 in-band NTP-64 timestamps for rapid synchronization. The example also allows spawning an arbitrary number of audio and/or video streams.

This also depends on the following merged MRs:

RFC 7273 clock signalling & synchronization

This commit implements RFC 7273 (NTP & PTP clock signalling & synchronization) for webrtcsink by adding the "ts-refclk" & "mediaclk" SDP media attributes to identify the clock. These attributes are handled by rtpjitterbuffer on the consumer side. They MUST be part of the SDP offer.

When used with an NTP or PTP clock, "mediaclk" indicates the RTP offset at the clock's origin. Because the payloaders are not instantiated when the offer is sent to the consumer, the RTP offset is set to 0 and the payloader timstamp-offsets are set accordingly when they are created.

The webrtc-precise-sync examples were updated to be able to start with an NTP (default), a PTP or the system clock (on the receiver only). The rtp jitter buffer will synchronize with the clock signalled in the SDP offer provided the sender is started with --do-clock-signalling & the receiver with --expect-clock-signalling.

FIXME:

  • With a PTP clock, the reference timestamp stays at 00:00:00.000 on the receiver overlay, while the reference timestamp meta is detected by the pad probe. timeoverlay needs to be provided with the meta's reference via the property reference-timestamp-caps.
  • When the receiver is configured to start with a PTP clock and clock signalling is enabled and the signalled clock is a PTP clock, an intermittent assertion failure in H264 parsers can occur. Doesn't occur when rtp-latency is increased. gst_h264_parse_process_backlog: assertion failed: (h264parse->nal_backlog->len > 0). Fixed by discarding retransmission on the receiver. See comment in code for references to related known issues.
Edited by François Laignel

Merge request reports