Decoding a TS stream with difficulties - TS slightly broken in 1.2?

Wed Sep 25 12:42:16 PDT 2013

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

> 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
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=706872
> 
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel