GNOME Bugzilla – Bug 796962
h264parse: wrong DTS calculation when not provided by the stream
Last modified: 2018-11-03 14:29:50 UTC
Created attachment 373333 [details] 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) ?
Created attachment 373334 [details] [review] tsdemux: force DTS = PTS when no DTS Add the proposed patch
Created attachment 373335 [details] TS sample file Add a sample of the TS stream from my encoder.
Created attachment 373745 [details] [review] Allow DTS from PTS infering even if PTS interpolation is disabled Further analysis shows a possible problem with DTS/PTS inference in gstbaseparse.c. The first video frame is pushed with PTS = 0:00:02.518099556 and infered DTS = 0:00:00.000000000 0:00:00.530085680 LOG baseparse gstbaseparse.c:2391:gst_base_parse_push_frame:<h264parse0> processing buffer of size 82147 with dts 0:00:00.000000000, pts 0:00:02.518099556, duration 0:00:00.016666666 If my understanding is correct, DTS inferring from PTS is not done (and I think it should because infer_ts is true) and only relies on next_dts value, which is initialized to 0. Consequently, a wrong DTS value is set in the buffer, resulting in a gap between PTS and inferred DTS. I was tempted to allow DTS infering even if PTS interpolation is disabled (please refer to the attached patch) but it partially reverts the following patch: commit f27a3e12f6d35695ebbf2edc5aa4937c2e7c3843 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Tue Apr 23 11:47:54 2013 +0200 baseparse: Only infer TS if PTS interpolation is enabled Otherwise this is breaking timestamps of formats that need reordering. https://bugzilla.gnome.org/show_bug.cgi?id=597662 So, it may be a bad idea. Do you have other suggestions ?
Review of attachment 373745 [details] [review]: It's kind of odd change, we added GST_BUFFER_DTS_OR_PTS() macro for this case. Don't we just need to port the code to use that ?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/769.