[Bug 796962] New: Failed to transmux UDP TS to RTMP FLV

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 796962
           Summary: Failed to transmux UDP TS to RTMP FLV
    Classification: Platform
           Product: GStreamer
           Version: 1.14.x
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: gaylord.charles at veo-labs.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
                CC: sebastien.matz at veo-labs.com
     GNOME version: ---

Created attachment 373333
  --> https://bugzilla.gnome.org/attachment.cgi?id=373333&action=edit
Logs with GST_DEBUG="tsdemux:5,baseparse:6,h264parse:5"

I experienced some problems while transmuxing an UDP TS stream (from a live
streaming hardware encoder) to a RTMP stream with the following pipeline
(Gstreamer 1.14.2):

gst-launch-1.0 flvmux name=mux streamable=true ! queue ! rtmpsink
location=rtmp://192.168.1.26:1935/live/my_stream \
udpsrc uri=udp://192.168.1.43:9001 do-timestamp=false ! queue ! tsdemux
name=dem \
dem. ! h264parse ! queue ! mux. dem. ! aacparse ! queue ! mux.

My encoder produces a H.264 + AAC program.
There are no errors while running the pipeline but the RTMP server is not able
to correctly play the received stream.

After some debugging (GST_DEBUG="tsdemux:5,baseparse:6,h264parse:5"), I found
out a possible problem with the DTS calculation on H.264 stream.
Here is an example of the logs from baseparse (the full log file is available
as an attachment):

0:00:00.575681258  LOG  baseparse
gstbaseparse.c:2147:gst_base_parse_handle_buffer:<h264parse0> handling buffer
of size 8174 with dts 0:00:00.033333332, pts 0:00:02.551755111, duration
99:99:99.999999999


The origin of the bug lays in the TS where DTS is not provided:

0:00:00.530313511  DEBUG  tsdemux
tsdemux.c:2297:gst_ts_demux_parse_pes_header:<dem> stream PTS 0:00:02.551755111
DTS 99:99:99.999999999

The compliance of such a stream is debatable, but there are no B frames in the
H.264 stream from the encoder. So we could assume DTS = PTS.

I made a quick (and dirty) fix in tsdemux.c (please refer to the attached
patch) to make my pipeline work (and the video correctly decoded on the RTMP
server).
Do you have any suggestions to solve this cleanly (maybe in h264parse or
baseparse) ?

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