After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 760005 - rtsp-sdp: Implement clock signalling according to RFC7273
rtsp-sdp: Implement clock signalling according to RFC7273
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
unspecified
Other All
: Normal enhancement
: 1.9.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-12-30 16:45 UTC by Sebastian Dröge (slomo)
Modified: 2016-04-03 08:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
rtsp-sdp: Implement clock signalling according to RFC7273 (4.58 KB, patch)
2015-12-30 16:45 UTC, Sebastian Dröge (slomo)
none Details | Review
rtsp-sdp: Implement clock signalling according to RFC7273 (4.56 KB, patch)
2015-12-31 15:21 UTC, Sebastian Dröge (slomo)
none Details | Review
rtsp-sdp: Implement clock signalling according to RFC7273 (7.12 KB, patch)
2016-02-18 11:18 UTC, Sebastian Dröge (slomo)
none Details | Review
rtsp-sdp: Implement clock signalling according to RFC7273 (21.87 KB, patch)
2016-02-18 17:04 UTC, Sebastian Dröge (slomo)
none Details | Review
rtsp-sdp: Implement clock signalling according to RFC7273 (21.89 KB, patch)
2016-02-23 15:20 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Sebastian Dröge (slomo) 2015-12-30 16:45:44 UTC
See commit message
Comment 1 Sebastian Dröge (slomo) 2015-12-30 16:45:49 UTC
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.
Comment 2 Sebastian Dröge (slomo) 2015-12-31 15:21:47 UTC
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.
Comment 3 Sebastian Dröge (slomo) 2015-12-31 15:55:36 UTC
This should probably go into libgstsdp in some way now.
Comment 4 Sebastian Dröge (slomo) 2016-01-04 17:12:05 UTC
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).
Comment 5 Sebastian Dröge (slomo) 2016-01-30 23:54:58 UTC
An initial WIP patch for rtpjitterbuffer can be found here: http://cgit.freedesktop.org/~slomo/gst-plugins-good/log/?h=rfc7273
Comment 6 Sebastian Dröge (slomo) 2016-02-18 11:18:09 UTC
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.
Comment 7 Sebastian Dröge (slomo) 2016-02-18 17:04:47 UTC
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.
Comment 8 Sebastian Dröge (slomo) 2016-02-18 17:23:15 UTC
This should be good to go now, comes with some new additional API :) I'll merge after 1.8.0 if nobody has objections.
Comment 9 Sebastian Dröge (slomo) 2016-02-23 15:20:24 UTC
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.
Comment 10 Sebastian Dröge (slomo) 2016-04-03 08:23:14 UTC
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