<div dir="ltr"><div><div><div><div>Hi.<br><br></div>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:<br><br> $ 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<br>
<br></div><div>It should be noted, that the pipeline reports the following problem, but otherwise seem to be happy:<br><br>WARNING: from element /GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0: Internal data flow problem.<br>
Additional debug info:<br>gstbasesink.c(3264): gst_base_sink_chain_unlocked (): /GstPipeline:pipeline0/GstTCPServerSink:tcpserversink0:<br>Received buffer without a new-segment. Assuming timestamps start from 0.<br><br></div>
<div>
<br></div>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:<br><br> $ gst-launch-1.0 -v tcpclientsrc host=192.168.1.2 port=5012 ! queue ! identity silent=true ! decodebin name=decoder ! autoaudiosink decoder. ! autovideosink<br>
<br></div>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<br>
<br><a href="https://bugzilla.gnome.org/show_bug.cgi?id=706872" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=706872</a><br><br></div>2) Second experiment. Trying to play just the video and just the audio. Here I use the following receiver pipelines:<br>
<br> $ gst-launch-1.0 -v tcpclientsrc host=192.168.1.2 port=5012 ! queue ! decodebin name=decoder ! autovideosink<br><br> $ gst-launch-1.0 -v tcpclientsrc host=192.168.1.2 port=5012 ! queue ! decodebin name=decoder ! autoaudiosink<br>
<br><div><div><div>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?<br><br>3) Third experiment. Trying to decode myself NOT using decodebin. Here I use the following receiver pipeline:<br>
<br> $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<br><br> $ 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<br>
<br></div><div>The video plays, but as with decodebin, it takes about 15 seconds before video is displayed AND played.<br><br></div><div>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.<br>
<br></div><div>Now to change the sender into 2 channel audio, I now uses this pipeline:<br><br> $ 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<br>
<br></div><div>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?<br><br></div><div>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 ???<br>
<br></div><div>Anyway, sender is now producing 2 channel audio, at least it says so.<br><br></div><div>Another thing to consider is that the producer end produces audio mpegversion=4 while the consumer ends reports audio mpegversion=2. Strange.<br>
</div><div><br></div><div>Now lets try to combine the working audio and working video decoding and playing using the following pipeline:<br><br> $ 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<br>
<br></div><div>However that pipeline enters PREROLL'ing, but never reaches PLAYING. Why is that and what can be done to make it playing ?<br><br></div><div>I have a few more tests that fails, but lets keep it to this for the now.<br>
<br></div><div>Comments are welcome ?<br><br></div><div>Best regards<br></div><div>Peter Maersk-Moller<br></div><div><br><br></div><div><br></div><div><br><br></div><div><br></div><div><br><div><br></div></div></div></div>
</div>