How do I use a 90KHz input device clock?

John P Poet jppoet at
Mon Jun 22 15:44:32 PDT 2015

On Wed, Jun 17, 2015 at 1:12 AM, Sebastian Dröge <sebastian at>

> On Di, 2015-06-16 at 16:08 -0600, John P Poet wrote:
> > Hi all,
> >
> > I am fairly new to gstreamer so I apologize for being clueless.  I
> > have tried to figure this out myself, but am just spinning my wheels
> > at this point.
> >
> > I am working on writing a src plugin for the Euresys Picolo H.264
> > cards:
> >
> > which has an on-board 90KHz clock.
> >
> > I decided to use Slomo's work on the decklink src as a template:
> >
> > -blackmagic-decklink-cards/
> > and I generally have it working.  Except for the clock.
> Did you take a look at the code of decklinkvideosrc, and especially the
> clock handling? That should have everything you need, including the
> relatively complicated calculations for slaving the capture clock to
> whatever clock was selected for the pipeline.

Yes, but it is possible that I am not understanding the reason for the

> The decklinkvideosrc code is very much written for the behaviour of
> that hardware's clock though, you will need to understand what it is
> trying to do and then adjust that for the behaviour of your hardware's
> clock.

Can you explain how the Decklink's clock works?  I am probably making bad
assumptions there.

> In any case, for a pipeline where your clock is selected as pipeline
> clock, the idea basically is that the timestamps on the buffers are the
> capture clock times minus the base time. That is, minus the clock time
> when the pipeline went to PLAYING. That way your timestamps will start
> approximately around zero if your source starts together with the
> pipeline.

That matches with what I am seeing.  However, I don't see how that is being
achieved in the decklink code.  I see that the decklink code keeps its own
concept of 'clock_start_time' but how does that differs/relates to the
pipelines base time.

Additionally you have to report the latency with the LATENCY query. A
> frame will be captured at clock time X, but it will only be available
> to you at least 1/framerate later, probably even more. That value has
> to be reported as minimum latency.

Thanks, that helps me understand that part.

For the case when another clock is selected as pipeline clock, you will
> have to convert capture times from your clock times to the pipeline
> clock times. For that the clock slaving feature in GstClock exists,
> where you can set a master clock on your clock which then causes
> regular observations between both clocks to happen and automatic
> adjustment of the clock parameters (the calibration). If you now get
> those parameters, you will get a time for both clocks that were
> observed at the same time (offset) and a relative rate between both
> clocks. That gives you all information you need for converting the
> clock times.

Since the video and audio from the Picolo are from the same clock source,
this is not necessary between those two, right?

> > If I don't set the timestamp for the buffer at all, then it it seems
> > to work.  However if I include the line:
> >
> > GST_BUFFER_TIMESTAMP (*buffer) = timestamp;
> >
> > in my gst_picoloh264_video_src_create() and
> > gst_picoloh264_audio_src_create() routines then I run into trouble.
> >
> > The timestamp coming from the Picolo H.264 is running at 90KHz.  I
> > can convert that to nanoseconds using:
> >
> > time_stamp = gst_util_uint64_scale_int(time_stamp, 1000000, 90);
> >
> > but that leads to my first question:  Should I be using
> > gst_clock_set_calibration() and gst_clock_get_calibration() somehow
> > to achieve this instead?
> No, that's for slaving a clock to a master clock.

Okay, but I should be doing
time_stamp = gst_util_uint64_scale_int(time_stamp, 1000000, 90);
?  That seems to be necessary to convert the 90KHz into nanoseconds.  Since
you didn't to anything like that in the decklink code, I assume its clock
is already in nanoseconds.

Thanks, Sabastian.  I will look over the decklink code again and see if I
can make the pieces fit together.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gstreamer-devel mailing list