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

[Peter Maersk-Moller]

Hi Tim-Philipp

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.

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

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

For the NAL, yes that was a slip by me. Thanks.

Best regards

Peter MM

On Wed, Sep 25, 2013 at 9:42 PM, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:

> 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
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130926/1d8c0c77/attachment-0001.html>