AES sender pipeline options

[James Cowdery]

Sebastian,
Great to see your reply and thanks for your suggestions.

Here is my SDP:
v=0
o=- 123456789012345 0 IN IP4 10.202.150.191
s=my_stream
c=IN IP4 239.150.250.250/31
t=0 0
m=audio 5004 RTP/AVP 98
i=1L,1R
a=ts-refclk:ptp=IEEE1588-2008:d0-a4-b1-ff-fe-00-00-0c:0
a=mediaclk:direct=0
a=clock-domain:PTPv2 0
a=source-filter: incl IN IP4 239.150.250.250 10.202.150.191
a=rtpmap:98 L16/48000/2
a=framecount:48
a=ptime:1
a=recvonly
a=sync-time:0


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?
If so are the RTP payloaders able to access and use the PTP clock?

Thanks,
James




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/