h264parse: wrong DTS calculation when not provided by the stream
@gaylord.charles
Submitted by Gaylord Charles Link to original bug (#796962)
Description
Created attachment 373333
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) ?
Attachment 373333, "Logs with GST_DEBUG="tsdemux:5,baseparse:6,h264parse:5"":
gst_debug_dump.log
Version: 1.14.x