AES67 sender pipeline options

[Sebastian Dröge]

Hi James,

On Wed, 2019-01-30 at 11:45 -0600, James Cowdery wrote:
> 
> From SMPTE 2110-30 which specifies how to use AES67 in broadcast
> applications: 
> 
> /Note 1: The media clock and the network timebase share the SMPTE ST 2059-1
> epoch, with an offset of zero between
> the Media Clock and the RTP Clock, as specified in SMPTE ST 2110-10.
> Note 2: To maintain compatibility with other RTP implementations such as
> AES67, implementers ought to be mindful of
> the offset provisions in those RTP standards, and the possibility that the
> RTP Clock could be offset from the Media Clock.
> N/
> 
> I read that as transmitters should all use 0 but receivers should use the
> offset if specified. Now the ST 2110 suite of standards are mostly
> applicable to broadcast but to maximize compatibility for all applications
> vaguely related to broadcast, e.g. consoles, pro monitors etc. it would be
> safer to use 0 offset in transmitters.

Thanks, that's also how I would understand it. It is recommended for
receivers to handle non-0 offsets for compatibility reasons but
transmitters based on this standard alone should always use 0.

> Thanks for the other pointers. I'll try integrating rtpbin back and see what
> caused the discontinuities. My code is still setting timestamp-offset before
> the pipeline is set to run as setting it afterwards isn't effective so I
> have to directly sample the PTP clock hence the fudge factor. 170ms just
> seems a bit large.

Maybe you connected the RTP stream to the wrong pads of rtpbin? In your
case it should go to "send_rtp_sink_0" and will come out of
"send_rtp_src_0". If you had used the "recv_*" pads that would explain
the ~200ms delay.

For setting the "timestamp-offset" property, it's indeed a bit tricky
to set the correctly. The payloader will only make use of that property
once in the beginning when it receives the CAPS event from upstream.
But at that point you don't really know the buffer timestamp yet.

A solution would be to use a pad probe to intercept all serialized
events and store them, and then when the pad probe receives the first
buffer you can know based on its timestamps what to set the property
to... and before letting the buffer pass you would push through all the
events that you previously stored. It's a bit hackish but that should
work and give you 0ms instead of 8ms :)

> Anyway I now have something that is hacked and ugly but works and can be
> used as a reference. From here it will be easier to get things right. Would
> adding a block after the payloader that owns the timestamps make sense from
> an architectural standpoint? I need a structure that can react to PTP jumps
> if they occur mid-stream.

I think instead of fixing up timestamps afterwards you should rather
understand why there are discontinuities and solve the underlying
problem. It means that something is not working as expected further
upstream.

The RTP timestamps are solely based on the timestamps of the buffers
going into the payloader, so if those are wrong that's where you should
look (and fixing those timestamps would also be an option then).

You might want to put the audiobuffersplit element before the payloader
though. That will split buffers into equal-sized chunks as its main
job, but as a side-effect will also result in a perfectly timestamped
stream and will smooth out timestamp jitter (if that's the problem).

-- 
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/20190130/eb5cd46c/attachment.sig>