How do I use a 90KHz input device clock?
John P Poet
jppoet at gmail.com
Mon Jun 22 15:44:32 PDT 2015
On Wed, Jun 17, 2015 at 1:12 AM, Sebastian Dröge <sebastian at centricular.com>
> 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:
> > http://www.euresys.com/Products/picolo/PicoloH264series.asp
> > which has an on-board 90KHz clock.
> > I decided to use Slomo's work on the decklink src as a template:
> > https://coaxion.net/blog/2014/12/improved-gstreamer-support-for
> > -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
Can you explain how the Decklink's clock works? I am probably making bad
> 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
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...
More information about the gstreamer-devel