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

[Peter Maersk-Moller]

Hi.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130925/1032e1d9/attachment.html>