How do I use a 90KHz input device clock?

[John P Poet]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150616/15453a72/attachment.html>