<div dir="ltr"><div><div><div>Hi Tim-Philipp </div>Thanks for answering. So TS-muxing is broken until fixed one day. For the other things, channels and mpegversion I'll open another thread with more explanation and examples. </div><div>Now TS is broken, can you recommend another transport format instead that works well with GStreamer and tcpserversink? I have tried with mp4mux and qtmux for a MP4 transport format, but the producing stream reports the following: mp4muxer: Downstream is not seekable and headers can't be rewritten </div><div>I tried adding streamable=true, but that is reported to be deprecated and it does not make a difference. The pipeline used is this: gst-launch-1.0 -v videotestsrc do-timestamp=true is-live=true ! x264enc bitrate=500 ! h264parse ! 'video/x-h264, alignment=au, stream-format=avc, profile=(string)main' ! queue ! mp4muxer. audiotestsrc ! 'audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)2' ! faac ! aacparse ! 'audio/mpeg,mpegversion=4, stream-format=raw' ! queue ! mp4mux name=mp4muxer streamable=true ! tcpserversink host=0.0.0.0 port=5012 sync-method=2 </div><div> </div>For the NAL, yes that was a slip by me. Thanks. </div>Best regards <div><div><div><div><div><div class="gmail_extra"> </div><div class="gmail_extra">Peter MM </div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Sep 25, 2013 at 9:42 PM, Tim-Philipp Müller <<a href="mailto:t.i.m@zen.co.uk" target="_blank">t.i.m@zen.co.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> On Wed, 2013-09-25 at 20:24 +0200, Peter Maersk-Moller wrote: Hi Peter, alignment=nal doesn't exist for audio/mpeg. I didn't read your post in detail, but I think we have talked about all this before, and the root cause of your problems is still the same as last time, which you filed a bug for, namely that tsmux doesn't mark buffers with keyframes and delta units properly, which makes tcpserversink's "burst" functionality not work. Cheers -Tim <div><div class="h5"> > Trying test a TS stream with GStreamer-1.2 to see what is working and > what is not working. To do the test I am using the following producing > pipeline: > > $ gst-launch-1.0 -v videotestsrc do-timestamp=true is-live=true ! > x264enc bitrate=500 ! h264parse ! 'video/x-h264, alignment=au, > stream-format=byte-stream, profile=(string)main' ! queue ! tsmuxer. > audiotestsrc ! faac ! aacparse ! 'audio/mpeg,mpegversion=4, > stream-format=adts, alignment=nal' ! queue ! mpegtsmux name=tsmuxer ! > tsparse ! tcpserversink host=0.0.0.0 port=5012 sync-method=2 > > > It should be noted, that the pipeline reports the following problem, > but otherwise seem to be happy: > > WARNING: from > element /GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0: > Internal data flow problem. > Additional debug info: > gstbasesink.c(3264): gst_base_sink_chain_unlocked > (): /GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0: > Received buffer without a new-segment. Assuming timestamps start from > 0. > > > > > 1) First test is to see if we can play the stream and to see if it > starts 'quickly' in a loose definition. The pipeline used is this: > > $ gst-launch-1.0 -v tcpclientsrc host=192.168.1.2 port=5012 ! > queue ! identity silent=true ! decodebin name=decoder ! autoaudiosink > decoder. ! autovideosink > > > A couple of experiments reveals that audio starts playing after 2-4 > seconds, while video starts playing after 3-7 seconds. Notably, the > video is first shown with a frozen image, that will then starts moving > after a couple of seconds. The numbers are somwhat slower (1-3 secs) > compared to a similar stream produced with gstreamer-0.10 and I wonder > if the tcpserversink really starts with keyframes as instructed. So I > guess this bug also applies for version 1.2 > > <a href="https://bugzilla.gnome.org/show_bug.cgi?id=706872" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=706872</a> > > > 2) Second experiment. Trying to play just the video and just the > audio. Here I use the following receiver pipelines: > > $ gst-launch-1.0 -v tcpclientsrc host=192.168.1.2 port=5012 ! > queue ! decodebin name=decoder ! autovideosink > > $ gst-launch-1.0 -v tcpclientsrc host=192.168.1.2 port=5012 ! > queue ! decodebin name=decoder ! autoaudiosink > > Here I observe it takes pretty much 15-17 seconds before the video is > played. I wonder why. And it takes between 5-12 seconds before the > audio is heard. Anybody got a hint? > > 3) Third experiment. Trying to decode myself NOT using decodebin. Here > I use the following receiver pipeline: > > $gst-launch-1.0 -v tcpclientsrc host=192.168.1.2 port=5012 ! queue ! > tsdemux name=demux ! 'video/x-h264' ! queue ! h264parse ! avdec_h264 ! > xvimagesink > > $ gst-launch-1.0 -v tcpclientsrc host=192.168.1.2 port=5012 ! > queue ! tsdemux name=demux ! 'audio/mpeg' ! queue ! aacparse ! faad ! > audioconvert ! queue ! alsasink > > > The video plays, but as with decodebin, it takes about 15 seconds > before video is displayed AND played. > > > Audio on the other hand can be heard within a second or so, but with a > lot of static (noise/interruptions) which was not expected. Inspection > reveals the initial pipeline producer encode and mux a single channel > audio while the receiver side think it is 2 channels. I'm close to > think this is a bug, but would like to get confirmation on this. > > > Now to change the sender into 2 channel audio, I now uses this > pipeline: > > $ gst-launch-1.0 -v videotestsrc do-timestamp=true is-live=true ! > x264enc bitrate=500 ! h264parse ! 'video/x-h264, alignment=au, > stream-format=byte-stream, profile=(string)main' ! queue ! tsmuxer. > audiotestsrc ! 'audio/x-raw, format=(string)S16LE, > layout=(string)interleaved, rate=(int)44100, channels=(int)2' ! faac ! > aacparse ! 'audio/mpeg,mpegversion=4, stream-format=adts, > alignment=nal' ! queue ! mpegtsmux name=tsmuxer ! tsparse ! > tcpserversink host=0.0.0.0 port=5012 sync-method=2 > > > Nevertheless, that does not change anything on the receiver side, > still the A-tone (440Hz) with a lot of static blended in. Can others > confirm this? > > > Rechecking the first experiment with decodebin that worked, it also > reports 2 channels for audio despite only a single channel audio is > produced. Something is not quite right here although it work. Both > sender and receiver can't be right. Either we have 1 or 2 channel > audio ??? > > > Anyway, sender is now producing 2 channel audio, at least it says so. > > > Another thing to consider is that the producer end produces audio > mpegversion=4 while the consumer ends reports audio mpegversion=2. > Strange. > > > > Now lets try to combine the working audio and working video decoding > and playing using the following pipeline: > > $ gst-launch-1.0 -v tcpclientsrc host=192.168.1.2 port=5012 ! > queue ! tsdemux name=demux ! 'video/x-h264' ! queue ! h264parse ! > avdec_h264 ! xvimagesink demux. ! 'audio/mpeg' ! queue ! aacparse ! > faad ! alsasink > > > However that pipeline enters PREROLL'ing, but never reaches PLAYING. > Why is that and what can be done to make it playing ? > > > I have a few more tests that fails, but lets keep it to this for the > now. > > > Comments are welcome ? > > > Best regards > > Peter Maersk-Moller > > > > > > > > > > > > > > </div></div>> _______________________________________________ > 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" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</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" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </blockquote></div> </div></div></div></div></div></div></div>