<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi all,<br><br></div>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.<br><br></div>I am working on writing a src plugin for the Euresys Picolo H.264 cards:<br><a href="http://www.euresys.com/Products/picolo/PicoloH264series.asp">http://www.euresys.com/Products/picolo/PicoloH264series.asp</a><br></div>which has an on-board 90KHz clock.<br><br></div>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-blackmagic-decklink-cards/">https://coaxion.net/blog/2014/12/improved-gstreamer-support-for-blackmagic-decklink-cards/</a><br></div>and I generally have it working.  Except for the clock. <br></div><br></div>If I don't set the timestamp for the buffer at all, then it it seems to work.  However if I include the line:<br><br>GST_BUFFER_TIMESTAMP (*buffer) = timestamp;<br></div><br>in my gst_picoloh264_video_src_create() and 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 can convert that to nanoseconds using:<br><br>time_stamp = gst_util_uint64_scale_int(time_stamp, 1000000, 90);<br></div><br>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?<br><br></div>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.<br><br>I run into a problem, though, if both the audio and video are part of the pipeline.<br><br>This works:<br>gst-launch-1.0 picoloh264videosrc location="/mnt/picolo_u16" connector=0 ! h264parse ! mux. mpegtsmux name=mux ! filesink location=picolo.ts<br><br></div>This works:<br>gst-launch-1.0 picoloh264audiosrc location="/mnt/picolo_u16" connector=0 ! audioconvert ! lamemp3enc ! queue ! mux. mpegtsmux name=mux ! filesink location=picolo.ts<br><br></div>If I set the timestamp of each buffer, then this does not work:<br>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<br><br></div>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.<br><br></div>I discovered, that if I force the timestamps to start at zero that it seems to solve the problem.  Doing something like:<br>timestamp -= self->input->clock_start_time;<br></div>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.<br><br></div>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?<br></div><br></div>Any help increasing my understanding of how this stuff works would be greatly appreciated.<br><br></div>John<br><br><div><div><div><div><br></div></div></div></div></div>