<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Thanks for the answers :) , they're really helpful. I played a bit with the code and here are some comments. If there is a mistake, I would be thankful for correction.</div><div><br></div><div>For the pipeline like that (no queues):</div><div><br></div><div>gst-launch-1.0 -v filesrc location=working.mp4 ! qtdemux name=a a. ! 
avdec_h264 ! videoconvert ! autovideosink a. ! avdec_aac ! autoaudiosink</div><div><br></div><div>It looks that autoaudiosink (checked by aborting the process and inspecting coredump) blocks the pipeline while calling the function gst_base_sink_wait_preroll:</div><div><br></div><div>GstFlowReturn<br>gst_base_sink_wait_preroll (GstBaseSink * sink)<br>{<br>  sink->have_preroll = TRUE;<br>  GST_DEBUG_OBJECT (sink, "waiting in preroll for flush or PLAYING");<br>  /* block until the state changes, or we get a flush, or something */<br>  GST_BASE_SINK_PREROLL_WAIT (sink); <-- HERE IT'S BLOCKING<br></div><div>[...]</div><div><br></div><div>It happens when all elements in the pipeline are changing state from READY to PAUSED. There is a buffer sent from qtdemux->avdec_aac->autoaudiosink and in the end of the chained call, in the audio sink there is called the function gst_base_sink_wait_preroll which blocks <span>infinitely</span>. Then perhaps it blocks qtdemux from sending video frames to preroll video sink since it all happens in the same thread. In the end, the state of all elements doesn't go to PAUSED and then PLAYING.</div><div><br></div><div>However when there are queues between demuxer and decoders, then the demuxer, video sink and audio sink all live in their own threads. Demuxer is gently pushing buffers to the queues in one thread and decoders in their own threads pick them up. In the end all sinks are prerolled and the state of pipeline can change to PAUSED and then PLAYING.</div><div><br></div><div>Best regards,</div><div>Wudo<br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">śr., 6 mar 2019 o 16:43 David Ing <<a href="mailto:ding@panopto.com">ding@panopto.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">I have also learned that queues are needed on the branches of a tee (for probably the same reasons).<div><br></div><div>For more information on what I learned about queues and tees:  <a href="http://gstreamer-devel.966125.n4.nabble.com/Usage-of-tee-with-queue-td4689894.html" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/Usage-of-tee-with-queue-td4689894.html</a></div><div><br></div><div>There is also some great documentation about how queues function as thread boundaries:  <a href="https://gstreamer.freedesktop.org/documentation/application-development/advanced/threads.html" target="_blank">https://gstreamer.freedesktop.org/documentation/application-development/advanced/threads.html</a></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 6, 2019 at 3:45 AM Mathieu Duponchelle <<a href="mailto:mathieu@centricular.com" target="_blank">mathieu@centricular.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    This is a classical problem, and a good illustration why you usually
    need queues after elements<br>
    with N src pads, and before elements with N sink pads:<br>
    <br>
    The demuxer is pushing to its source pads from the same thread, and
    if you have connected<br>
    these source pads with sync=true sinks, their chain function blocks
    until prerolling is done,<br>
    that is until each sink with sync=true has received a buffer. Adding
    queues decouples branches of<br>
    the pipeline, as they will start their own streaming thread.<br>
    <br>
    <div class="gmail-m_-6973520104236790070gmail-m_-8977084316196909206moz-cite-prefix">On 3/5/19 11:11 PM, Wudo Balmus wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">
            <div dir="ltr">
              <div>Hello,</div>
              <div>I'm trying to demux and playback an mp4 file with
                h.264 video and aac audio. This pipeline works fine:</div>
              <div><br>
              </div>
              <div>gst-launch-1.0 -v filesrc location=working.mp4 !
                qtdemux name=a a. ! queue ! avdec_h264 ! videoconvert !
                autovideosink a. ! queue ! avdec_aac ! autoaudiosink</div>
              <div><br>
              </div>
              <div>However when the queues are removed, it hangs,
                nothing is played back:</div>
              <div><br>
              </div>
              <div>gst-launch-1.0 -v filesrc location=working.mp4 !
                qtdemux name=a a. ! avdec_h264 ! videoconvert !
                autovideosink a. ! avdec_aac ! autoaudiosink</div>
              <div><br>
              </div>
              <div>It works fine without a queue when I just try to
                playback video without audio:</div>
              <div><br>
              </div>
              <div>gst-launch-1.0 -v filesrc location=working.mp4 !
                qtdemux name=a a. ! avdec_h264 ! videoconvert !
                autovideosink</div>
              <div><br>
              </div>
              <div>I'm trying to understand why queues are necessary in
                this scenario. Cannot qtdemux just write data to
                video/audio decoder without the queues?<br>
              </div>
              <div><br>
              </div>
              <div>Best regards,</div>
              <div>Wudo<br>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="gmail-m_-6973520104236790070gmail-m_-8977084316196909206mimeAttachmentHeader"></fieldset>
      <pre class="gmail-m_-6973520104236790070gmail-m_-8977084316196909206moz-quote-pre">_______________________________________________
gstreamer-devel mailing list
<a class="gmail-m_-6973520104236790070gmail-m_-8977084316196909206moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>
<a class="gmail-m_-6973520104236790070gmail-m_-8977084316196909206moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></pre>
    </blockquote>
  </div>

_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div></div>