<div dir="ltr"><div><div><div>Hi </div>Okay so I got a little bit closer to determine why a pipeline working with 1.6.0 doesn't work with 1.6.1-1.6.3. Doesn't work means stream stops flowing out of the muxer after 1-2 secs. </div>The pipeline was. <div style="margin-left:40px">gst-launch-1.0 -v fdsrc fd=0 do-timestamp=1 !\ </div><div style="margin-left:80px">audio/x-raw,format=S16LE,channels=2,layout=interleaved,rate=44100 !\ queue leaky=2 !\ audiorate skip-to-first=1 silent=0 !\ audioconvert !\ avenc_aac bitrate=128000 compliance=-2 !\ audio/mpeg,mpegversion=4,stream-format=raw !\ aacparse !\ queue !\ mux. shmsrc socket-path=/tmp/mixer1 do-timestamp=1 is-live=1 !\ queue max-size-bytes=0 leaky=2 max-size-buffers=30 !\ video/x-raw,format=BGRA,width=1280,height=720,framerate=30/1 !\ videoconvert !\ videorate skip-to-first=1 !\ queue !\ x264enc bitrate=4000 speed-preset=6 key-int-max=60 bframes=0 !\ video/x-h264,alignment=au,stream-format=byte-stream,profile=high !\ h264parse !\ queue !\ mpegtsmux name=mux alignment=7 !\ queue !\ identity silent=0 ! fakesink </div> Turns out, that if I remove the 'aacparse', the stream flows, but I have problem decoding it in another pipline. That's something with mpegtsmux require adts and a decoding in another pipeline fails detecting it correctly and tries decoding it as MPEG-2. I believe I or others have reported that before, but have forgot the ticket. </div>Now the interesting part is that if I instead of removing the aacparse, I replace avenc_aac with faac, then things works for 1.6.1-1.6.3 too. Once again faac just work, where other aac encoders fail. So apparently something changed from 1.6.0 to 1.6.1 for either: <ol><li>avenc_aac</li><li>aacparse</li><li>mpegtsmux</li></ol>Or something fundamentally changed with buffers and queues resulting in a lockup situation. I'll try to investigate further. I don't feel this is enough yet for a meaningful bug report. Suggestions are welcome. Best regardsPeter </div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Jan 20, 2016 at 4:18 PM, Sebastian Dröge <<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mi, 2016-01-20 at 15:57 +0100, Peter Maersk-Moller wrote: > Hi > > I have a pipeline, that works well with versions up until 1.6.0, but > does not seem to work for 1.6.1 and 1.6.2. Will check 1.6.3 soon. So > my question is, what was changed that will make data stop flowing > with 1.6.1 and beyond that was working with 1.6.0 and earlier? > > I do not get any warning messages or error messages and the pipeline > is reporting to enter the PLAY state. To test if the the pipeline is > flowing, I simply make a tcp connection to the pipelines > tcpserversink and see if data is flowing from it. Here is the > pipeline. > [...] Can you file a bug about this with instructions how to reproduce the problem? Thanks :) <a href="https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer" rel="noreferrer" target="_blank">https://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer</a> -- Sebastian Dröge, Centricular Ltd · <a href="http://www.centricular.com" rel="noreferrer" target="_blank">http://www.centricular.com</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>