<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 17, 2015 at 12:53 AM, Peter Körner <<a href="mailto:osm-lists@mazdermind.de" target="_blank">osm-lists@mazdermind.de</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 <<a href="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-clock-obligations-of-each-element.html" rel="noreferrer" target="_blank">http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-clock-obligations-of-each-element.html</a>> Regards, Peter </blockquote><div> </div><div> Thank you for the pointer. It is possible I am not doing this correctly: <div class=""><div><div><h3 class="">Live source elements </h3></div></div></div> 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 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div><div class="h5"> 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: > <a href="http://www.euresys.com/Products/picolo/PicoloH264series.asp" rel="noreferrer" target="_blank">http://www.euresys.com/Products/picolo/PicoloH264series.asp</a> > which has an on-board 90KHz clock. > > I decided to use Slomo's work on the decklink src as a template: > <a href="https://coaxion.net/blog/2014/12/improved-gstreamer-support-for-blackmagic-decklink-cards/" rel="noreferrer" target="_blank">https://coaxion.net/blog/2014/12/improved-gstreamer-support-for-blackmagic-decklink-cards/</a> > 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 > > > > </div></div>> _______________________________________________ > gstreamer-devel mailing list > <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> > _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </blockquote></div> </div></div>