How do I use a 90KHz input device clock?

[Peter Körner]

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


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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150617/c18bf4ee/attachment-0001.sig>