AES67 sender pipeline options

[James Cowdery]

Sebastian,

>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 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.
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.
James




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