Created attachment 318047 [details] [review]
rtsp-sdp: Implement clock signalling according to RFC7273

For NTP and PTP clocks we signal the actual clock that is used and signal
the direct media clock offset.

For all other clocks we at least signal that it's the local sender clock.

This allows receivers to know which clock was used to generate the media and
its RTP timestamps. Receivers can then implement network synchronization,
either absolute or at least relative by getting the sender clock rate directly
via NTP/PTP instead of estimating it from RTP timestamps and packet receive
times.

Created attachment 318078 [details] [review]
rtsp-sdp: Implement clock signalling according to RFC7273

For NTP and PTP clocks we signal the actual clock that is used and signal
the direct media clock offset.

For all other clocks we at least signal that it's the local sender clock.

This allows receivers to know which clock was used to generate the media and
its RTP timestamps. Receivers can then implement network synchronization,
either absolute or at least relative by getting the sender clock rate directly
via NTP/PTP instead of estimating it from RTP timestamps and packet receive
times.

This should probably go into libgstsdp in some way now.

Also should probably be optional, or at least the offset part should not happen for non-live streams. The offset will lead to wrong timestamps when pausing or seeking unless we change rtpbasepayload to use the clock time instead of the running time for generating the RTP timestamps (in which case there would be a gap of the duration of the pausing for example).

An initial WIP patch for rtpjitterbuffer can be found here: http://cgit.freedesktop.org/~slomo/gst-plugins-good/log/?h=rfc7273

Created attachment 321577 [details] [review]
rtsp-sdp: Implement clock signalling according to RFC7273

For NTP and PTP clocks we signal the actual clock that is used and signal
the direct media clock offset.

For all other clocks we at least signal that it's the local sender clock.

This allows receivers to know which clock was used to generate the media and
its RTP timestamps. Receivers can then implement network synchronization,
either absolute or at least relative by getting the sender clock rate directly
via NTP/PTP instead of estimating it from RTP timestamps and packet receive
times.

Created attachment 321604 [details] [review]
rtsp-sdp: Implement clock signalling according to RFC7273

For NTP and PTP clocks we signal the actual clock that is used and signal
the direct media clock offset.

For all other clocks we at least signal that it's the local sender clock.

This allows receivers to know which clock was used to generate the media and
its RTP timestamps. Receivers can then implement network synchronization,
either absolute or at least relative by getting the sender clock rate directly
via NTP/PTP instead of estimating it from RTP timestamps and packet receive
times.

This should be good to go now, comes with some new additional API :) I'll merge after 1.8.0 if nobody has objections.

Created attachment 321985 [details] [review]
rtsp-sdp: Implement clock signalling according to RFC7273

For NTP and PTP clocks we signal the actual clock that is used and signal
the direct media clock offset.

For all other clocks we at least signal that it's the local sender clock.

This allows receivers to know which clock was used to generate the media and
its RTP timestamps. Receivers can then implement network synchronization,
either absolute or at least relative by getting the sender clock rate directly
via NTP/PTP instead of estimating it from RTP timestamps and packet receive
times.

commit 9fab555cc598d701b8911926193f8005471e2ded
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Wed Dec 30 18:39:05 2015 +0200

    rtsp-server: Implement clock signalling according to RFC7273
    
    For NTP and PTP clocks we signal the actual clock that is used and signal
    the direct media clock offset.
    
    For all other clocks we at least signal that it's the local sender clock.
    
    This allows receivers to know which clock was used to generate the media and
    its RTP timestamps. Receivers can then implement network synchronization,
    either absolute or at least relative by getting the sender clock rate directly
    via NTP/PTP instead of estimating it from RTP timestamps and packet receive
    times.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=760005