How do I use a 90KHz input device clock?

[John P Poet]

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

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


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

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150622/7858f024/attachment.html>