How do I use a 90KHz input device clock?

[John P Poet]

On Wed, Jun 17, 2015 at 12:53 AM, Peter Körner <osm-lists at mazdermind.de>
wrote:

> Hi,
>
> Have you thought about implementing a custom GstClock subclass and
> provide your clocking that way? alsasink does that for example.
>
> Regarding your buffer Timestamps - and not being an expert in this - did
> you send a correct Segment-Event before starting to push buffers?
>
> See
> <
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-clock-obligations-of-each-element.html
> >
>
> Regards, Peter
>


Thank you for the pointer.  It is possible I am not doing this correctly:

Live source elements

Live source elements must place a timestamp in each buffer that they
deliver. They must choose the timestamps and the values of the SEGMENT
event in such a way that the running-time of the buffer matches exactly the
running-time of the pipeline clock when the first byte in the buffer was
captured.


Do you know of an example which implements that?

Thanks,

John



>
> On 17.06.2015 00:08, 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.
> >
> > 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?
> >
> > Video and Audio are read completely independently from each other and my
> > gstpicoloh264videosrc and gstpicoloh264videosrc work independently just
> > fine.  Like I said, I used Slomo's decklinksrc as a template, and the
> > only major change was to allow the audiosrc to be the master clock, if
> > the videosrc is not part of the pipeline.
> >
> > I run into a problem, though, if both the audio and video are part of
> > the pipeline.
> >
> > This works:
> > gst-launch-1.0 picoloh264videosrc location="/mnt/picolo_u16" connector=0
> > ! h264parse ! mux. mpegtsmux name=mux ! filesink location=picolo.ts
> >
> > This works:
> > gst-launch-1.0 picoloh264audiosrc location="/mnt/picolo_u16" connector=0
> > ! audioconvert ! lamemp3enc ! queue ! mux. mpegtsmux name=mux ! filesink
> > location=picolo.ts
> >
> > If I set the timestamp of each buffer, then this does not work:
> > gst-launch-1.0 picoloh264videosrc location="/mnt/picolo_u16" connector=0
> > ! h264parse ! queue ! mux. picoloh264audiosrc location="/mnt/picolo_u16"
> > connector=0 ! audioconvert ! lamemp3enc ! queue ! mux. mpegtsmux
> > name=mux ! filesink location=picolo.ts
> >
> > The resulting file has video but no audio.  Looking at the logging,
> > picoloh264audiosrc generates about 8 packets and then stalls.  It looks
> > like those packets are making it to lamemp3enc but no further.
> >
> > I discovered, that if I force the timestamps to start at zero that it
> > seems to solve the problem.  Doing something like:
> > timestamp -= self->input->clock_start_time;
> > results in perfect audio/video in the resulting transport stream -- for
> > a while.  After many hours, problems with the audio muxing re-appear.
> > That simple subtraction of the start_time does not deal with the
> > on-board clock wrapping to zero, so that may be the issue and I will
> > look into that.
> >
> > However, I can't but help feel that I am doing something wrong.  Since
> > this is a 'live' source, why do I even need to force the timestamps to
> > start at zero?
> >
> > Any help increasing my understanding of how this stuff works would be
> > greatly appreciated.
> >
> > John
> >
> >
> >
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150622/82f09712/attachment.html>