<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 17, 2015 at 1:12 AM, Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Di, 2015-06-16 at 16:08 -0600, John P Poet wrote:<br> > Hi all,<br> ><br> > I am fairly new to gstreamer so I apologize for being clueless. I<br> > have tried to figure this out myself, but am just spinning my wheels<br> > at this point.<br> ><br> > I am working on writing a src plugin for the Euresys Picolo H.264<br> > cards:<br> > <a href="http://www.euresys.com/Products/picolo/PicoloH264series.asp" rel="noreferrer" target="_blank">http://www.euresys.com/Products/picolo/PicoloH264series.asp</a><br> > which has an on-board 90KHz clock.<br> ><br> > I decided to use Slomo's work on the decklink src as a template:<br> > <a href="https://coaxion.net/blog/2014/12/improved-gstreamer-support-for" rel="noreferrer" target="_blank">https://coaxion.net/blog/2014/12/improved-gstreamer-support-for</a><br> > -blackmagic-decklink-cards/<br> > and I generally have it working. Except for the clock.<br> <br> </span>Did you take a look at the code of decklinkvideosrc, and especially the<br> clock handling? That should have everything you need, including the<br> relatively complicated calculations for slaving the capture clock to<br> whatever clock was selected for the pipeline.<br></blockquote><div><br></div><div>Yes, but it is possible that I am not understanding the reason for the steps.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> The decklinkvideosrc code is very much written for the behaviour of<br> that hardware's clock though, you will need to understand what it is<br> trying to do and then adjust that for the behaviour of your hardware's<br> clock.<br></blockquote><div><br></div><div>Can you explain how the Decklink's clock works? I am probably making bad assumptions there.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> In any case, for a pipeline where your clock is selected as pipeline<br> clock, the idea basically is that the timestamps on the buffers are the<br> capture clock times minus the base time. That is, minus the clock time<br> when the pipeline went to PLAYING. That way your timestamps will start<br> approximately around zero if your source starts together with the<br> pipeline.<br></blockquote><div><br></div><div><br>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.<br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Additionally you have to report the latency with the LATENCY query. A<br> frame will be captured at clock time X, but it will only be available<br> to you at least 1/framerate later, probably even more. That value has<br> to be reported as minimum latency.<br></blockquote><div><br></div><div>Thanks, that helps me understand that part. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> For the case when another clock is selected as pipeline clock, you will<br> have to convert capture times from your clock times to the pipeline<br> clock times. For that the clock slaving feature in GstClock exists,<br> where you can set a master clock on your clock which then causes<br> regular observations between both clocks to happen and automatic<br> adjustment of the clock parameters (the calibration). If you now get<br> those parameters, you will get a time for both clocks that were<br> observed at the same time (offset) and a relative rate between both<br> clocks. That gives you all information you need for converting the<br> clock times.<br></blockquote><div><br></div><div>Since the video and audio from the Picolo are from the same clock source, this is not necessary between those two, right?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <span class=""><br> > If I don't set the timestamp for the buffer at all, then it it seems<br> > to work. However if I include the line:<br> ><br> > GST_BUFFER_TIMESTAMP (*buffer) = timestamp;<br> ><br> > in my gst_picoloh264_video_src_create() and<br> > gst_picoloh264_audio_src_create() routines then I run into trouble.<br> ><br> > The timestamp coming from the Picolo H.264 is running at 90KHz. I<br> > can convert that to nanoseconds using:<br> ><br> > time_stamp = gst_util_uint64_scale_int(time_stamp, 1000000, 90);<br> ><br> > but that leads to my first question: Should I be using<br> > gst_clock_set_calibration() and gst_clock_get_calibration() somehow<br> > to achieve this instead?<br> <br> </span>No, that's for slaving a clock to a master clock.<br></blockquote><div><br></div><div>Okay, but I should be doing<br><span class="">time_stamp = gst_util_uint64_scale_int(time_stamp, 1000000, 90);<br>? 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.<br><br></span></div><div><span class="">Thanks, Sabastian. I will look over the decklink code again and see if I can make the pieces fit together.<br><br></span></div><div><span class="">John<br></span></div><div><span class=""><br></span></div></div></div></div>