[Bug 763278] New: tcpserversink problems with TS muxed stream.

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=763278

            Bug ID: 763278
           Summary: tcpserversink problems with TS muxed stream.
    Classification: Platform
           Product: GStreamer
           Version: 1.7.90
                OS: Linux
            Status: NEW
          Severity: blocker
          Priority: Normal
         Component: gst-plugins-base
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: pmaersk at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

I have a problem with the 1.7.90 version for the pipeline shown below. The
pipeline works fine for 1.6.3, but for 1.7.90, nothing comes out of the
tcpserversink although plenty of packets flows into it.

The flow out of tcpserversink is initally tested with the command

        nc localhost 5010 | od -c

and subesequently tested with both vlc and a gstreamer pipeline with
tcpclientsrc.

If the tcpserversink option 'sync-method=2' is removed from the pipeline,
then version 1.7.90 tcpserversink will send data, but VLC can never decode
it successfully. If the tcpserversink option 'sync-method=2' is removed
from the pipeline for 1.6.3, VLC and others can still play the stream, but
it can take longer to find the first image to decode.

Similar issues have been seen before where the problem usually has been
mpegtsmux not setting flags correct or in a way tcpserversink would expect.

Note that the live pipeline sets timestamps upon input and subseqently the
timestamps do not start from zero.

Think this needs to be resolved before 1.8.0 is released so we don't get a
stable release out there with a tsmux/tcpserversink issue, but that is just
a suggestion.

Below is the pipeline. I assume you would be able to create pipelines with
audiotestsrc and videotestsrc and feed these into the pipeline below with
fdsink and shmsink to emulate data into the pipeline NOT starting at time=0.


/usr/local/bin/gst-launch-1.0 -v fdsrc fd=0 do-timestamp=true ! queue !\
        audio/x-raw,format=S16LE,layout=interleaved, rate=44100,channels=2
!\
        queue ! audioconvert ! audiorate !\
        faac bitrate=128000 !\
        audio/mpeg,mpegversion=4, stream-format=raw !\
        aacparse ! queue !\
        muxer. shmsrc socket-path=/tmp/mixer1 do-timestamp=true
is-live=true !\

video/x-raw,format=BGRA,pixel-aspect-ratio=1/1,interlace-mode=progressive,width=1280,height=720,framerate=30/1
!\
        queue max-size-bytes=0 leaky=2 max-size-buffers=30 !\
        videoconvert ! queue !\
        x264enc bitrate=3499 tune=zerolatency speed-preset=6 key-int-max=60
bframes=0 !\
        video/x-h264,alignment=au,stream-format=byte-stream,profile=main !\
        h264parse ! queue !\
        mpegtsmux name=muxer !\
        tsparse ! queue ! tee name=tstream !\
        rtpmp2tpay !\
        udpsink host=127.0.0.1 port=10072 sync=false tstream. !\
        tcpserversink port=5010 host=0.0.0.0 sync-method=2

See also
https://lists.freedesktop.org/archives/gstreamer-devel/2016-March/057071.html

The bug is filed under tcpserversink, but I would guess it is an issue with
mpegtsmux/tcpserversink signalling, where tcpserversink may not recognize
correctly the flags mpegtsmux sets for identifying I-frames or it may be
something with timing.

The bug is marked for Linux, but that is because I have only tested for the
error on Linux.

Best regards
Peter Maersk-Moller

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.