AES sender pipeline options

[Sebastian Dröge]

Hi James,

On Thu, 2019-01-24 at 23:29 -0600, James Cowdery wrote:
> [...]
> I spent a bit more time on this today and I think I know what the problem
> is. From the AES67 spec. (section 5), the timestamps have to derived from
> the PTP clock. The timestamp is the number of audio sample periods since the
> Epoch modulo 32 (24.86 hours for 48kHz).
> So you have to get the time since the Epoch (1/1/70), which is your PTP
> clock (GstPtpClock.ptp-time), multiply it by the sampling frequency and then
> modulo 2^32 i.e. take the bottom 32 bits. I've inspected a good (Ravenna)
> AES67 stream, compared the timestamps with the PTP clock and this
> calculation seems to be right. I can reboot the AES67 sender and RTP
> timestamps are consistent i.e. an external clock is being used for the
> timestamps so that all makes sense.
> 
> Obviously the streams I've created start with a random or 0 offset so
> receivers compare that with their own PTP time (mod 32) and reject the
> stream when it is out of range. The error I am getting is 'packets could not
> be played back because they arrived too late.'
>
> I can't fix that with a fixed offset in the SDP because I don't know ahead
> of time exactly what the value of the PTP clock will be when the first
> packet goes out. All the Ravenna streams I've seen have the line
> 'a=mediaclk:direct=0' in the SDP so I've copied that.
> 
> Does all that make sense?
> Do you agree with my assessment?

Yeah, that's what I meant with the media clock offset: the
mediaclk:direct=XXXX line in the SDP.

> If so are the RTP payloaders able to access and use the PTP clock?

The way how it works in gst-rtsp-server is that the SDP is only created
when the stream itself is created. So during pipeline construction you
will exactly know the PTP time that corresponds to the very first RTP
packet that is sent out and can then calculate the media clock offset
accordingly.

An alternative would be to set the timestamp-offset property in the
payloader accordingly so that the first packet has the RTP timestamp
you expect, but that basically requires doing the same as in the first
case.

In either case, it's not the payloader's job to know the clock time
that corresponds to an RTP packet and timestamp accordingly. The
timestamping inside the payloader happens completely separate from the
clock based on the timestamp (and the running time calculated from
that) of the incoming buffers.
It is the job of the code building the pipeline to ensure that those
timestamps make sense in the GStreamer synchronization model.

So basically what you could do is when building your pipeline to catch
the very first packet/buffer that comes out of the payloader in a pad
probe. From there you can then get the PTS/running time and RTP
timestamp, can convert the running time to the corresponding clock time
when it should be rendered and based on that generate your SDP.

Or if the SDP must be static, you could do something similar before the
payloader and then based on that set the correct timestamp-offset
property so that the first RTP timestamp coming out of the payloader
would correspond to the fixed media clock offset.

-- 
Sebastian Dröge, Centricular Ltd · https://www.centricular.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190125/be366705/attachment.sig>