Hi all,<br>We have a problem with demuxer element (flutsdemux, but with others too). We are receiving transport stream over network and we are playing it with playbin2 element only. First couple of ES are video and only ofter 0.5s comes audio. At that point, Gstreamer says something like:<br>
<br>INFO        GST_ELEMENT_PADS gstelement.c:727:gst_element_add_pad:&lt;flutsdemux0&gt; adding pad &#39;audio_00c0&#39;<br>WARN              decodebin2 gstdecodebin2.c:2067:gst_decode_chain_get_current_group:&lt;decodebin20&gt; Currently active group 0x8d85540 is exposed and wants to add a new pad without having signaled no-more-pads<br>
WARN              decodebin2 gstdecodebin2.c:1299:analyze_new_pad:&lt;decodebin20&gt; No current group<br><br>Audio can&#39;t be heard at all. Similar situation occurs if first packet is audio (then audio is heard, but there is no video). Is there anything that can be done to overcome this &quot;problem&quot; (if it is a problem and whose element&#39;s problem is this at all)? Explanation of this behavior is also good to be heard, if someone have time to explain (google search didn&#39;t help much).<br>
<br>Also, since we use &quot;playbin2&quot; element in C code, I guess we can put proper callbacks and retrieve reference to flutsdemux element. Is there any code we can put somewhere there to somehow &quot;force&quot; demuxer to wait for both audio and video?<br>
<br>If it helps, the same transport stream is playing nicely when not streamed through network, but with local playback.<br><br>Thanks in advance, Branko<br>