<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 3, 2015 at 8:59 AM, Tim Müller <span dir="ltr"><<a href="mailto:tim@centricular.com" target="_blank">tim@centricular.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 2015-07-03 at 08:32 -0600, John P Poet wrote:<br>
<br>
Hi John,<br>
<span class=""><br>
> I am using:<br>
><br>
> gst-launch-1.0 picoloh264videosrc location="/mnt/picolo_u16"<br>
> connector=0 ! h264parse ! queue ! mux. picoloh264audiosrc<br>
> location="/mnt/picolo_u16" connector=0 ! audioconvert ! lamemp3enc !<br>
> queue ! mux. mpegtsmux name=mux ! filesink location=picolo.ts<br>
><br>
><br>
> Would it help to add some more queue elements?<br>
<br>
</span>I guess that shuold be ok as is, but try adding queues after the source<br>
element as well.<br></blockquote><div><br><br></div><div>That did not help.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
>         > I came across gst_pad_push_list(), but I get the impress<br>
>         that that is<br>
>         > not usable from within a _src_create() call-back.  Is that<br>
>         correct?<br>
><br>
>         That's correct. Also see<br>
>         <a href="https://bugzilla.gnome.org/show_bug.cgi?id=750241" rel="noreferrer" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=750241</a><br>
><br>
><br>
><br>
> That looks useful.  Is it stable enough for me to try?<br>
<br>
</span>The patches are not entirely up-to-date. I don't think it's what you<br>
need, in your scenario you should just output buffers. If that doesn't<br>
work properly, there's some other problem, perhaps with the timestamping<br>
of one or both of the streams.<br>
<br>
Look at the GST_DEBUG=*mux*:6,*collect*:6 debug log to see what<br>
timestamps the muxer pads are getting, the muxer might not be popping<br>
off buffers from one of the input pads for some reason.<br>
</blockquote><div><br></div><div>It is going to take me some time to analyze the result of this logging.  The first problematic input goes about 15 seconds before it starts to get behind.  I need to compare that to how it behaves when I am only using one of the inputs.<br></div></div><br></div><div class="gmail_extra">Thanks again for your help.<br><br></div><div class="gmail_extra">John<br></div></div>