<div dir="ltr">Sorry for typos in the earlier post. The constructed pipeline was originally: filesrc -> qtdemux -> qtmux frament=10000 -> multifilesink.<div><br></div><div>Realized that the mux element would need 2 threads to bring in the audio and video buffers simultaneously. I added two queues one each for audio and video buffers coming out of demux, and linked the queues to corresponding pads on qtmux.</div><div><br></div><div>- Kiran</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 16, 2015 at 6:01 PM, Kiran Nagaraja <span dir="ltr"><<a href="mailto:kiran.nagaraja@gmail.com" target="_blank">kiran.nagaraja@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,  <div><br></div><div>Building a simple application (using C bindings) with the following pipeline of elements:</div><div><br></div><div>filesink -> qtdemux -> qtmux -> filesink</div><div><br></div><div>I've set the filesink 'async' property to FALSE, and taken care of the dynamic pad linking btwn qtdemux and qtmux for both audio and video pads. </div><div><br></div><div>When run, the pipeline goes to the PLAYING state, but no buffers flow through it. </div><div><br></div><div>I suspect the 'stream-start' event didn't flow throw the pipeline since I don't see it in my bus event callback. When debugging with GST_EVENT:5, I see that there is stream-start event upto the mux element, but not for the filesink.  Buffers flow if were to remove the qtmux and sink directly. </div><div><br></div><div>GST_EVENT log can be found here: <a href="http://pastebin.com/nhxgt4f3" target="_blank">http://pastebin.com/nhxgt4f3</a></div><div><br></div><div>Am I missing some configuration?</div><div><br></div><div>Thanks,</div><div>- Kiran</div><div><br></div></div>
</blockquote></div><br></div>