Need advice with regards to a clock provider problem

[Carlos Rafael Giani]

Hello,

I have an audio sender-receiver system where the sender and the 
receivers need to play in sync. The sender sends out RTP packets, and 
inserts the GstBuffer PTS into extended RTP headers. The receiver reads 
out the PTS, and uses these as the PTS of the depayloaded GstBuffers. In 
other words, neither RTCP nor the RTP timestamps are used. This works 
really well for us (the RTP stream remains internal, and does not have 
to be compatible with anything else).

Sender and receiver are written as elements. Thus, they can also be used 
in a gst-launch command line for example. The sender inherits from 
GstBin, the receiver from GstPipeline.

So far, we were content with using whatever clock was selected as the 
pipeline clock in the sender for producing the PTS. We have been using 
the GstNetTimeProvider and the GstNetClientClock to synchronize the 
receiver clocks to the sender's.

In a recent development, a new time synchronization system is now 
available, which is extremely accurate. It would replace the 
GstNetTimeProvider and the GstNetClientClock. It does however require 
*both* the sender and receiver pipelines to use one specific clock as 
the pipeline clock. For the receiver, this change is minimal. For the 
sender, however, the change is a big deal, since until now, it just used 
whatever clock was chosen by the pipeline.

I see the following ways to deal with this problem:

1) The sender bin forces the pipeline to use its clock as the pipeline 
clock. Downsides: if there is a source that absolutely needs to use 
*its* clock, we have a collision. Plus, it is somewhat invasive for the 
sender bin to act like that, isn't it? Also, I do not see how this would 
be possible. An element cannot force the pipeline to do this, can it? An 
application can, by calling gst_element_use_clock() on the pipeline element.

2) The sender bin somehow uses this new clock only internally, and 
translates incoming PTS, DTS, segments etc. from the pipeline clock to 
the internal clock domain. This would be non-invasive, but also much 
more complicated. There would be potentially *three* clocks then: the 
pipeline clock, this custom time sync clock, and the audio clock (since 
the sender also plays locally). Quite messy :)

A compromise would be to do something like (1), except the sender would 
not actually force anything. Instead, the docs for this system would 
say: "if you use the sender, make sure its clock is always chosen by 
calling gst_element_use_clock(), and/or make sure the sources never 
provide their own clock". Not an elegant solution, but probably the most 
realistic one.

Thoughts?