Gstreamer v1.17.0 compiled yesterday with cerbero/master on win 10 x64, variants visualstudio, nvdocec and intelmsdk. I'm using HTML formatting because I added some images, hope it works well for everyone. Although I haven't been able to get the tracers to work, instead, I logged the PTS times on several pads in the pipeline by adding probes to them (gst_pad_add_probe(pad, GST_PAD_PROBE_TYPE_BUFFER, ...)). I don't have a thorough understanding of what PTS values mean, so I'm not sure this information is absolutely relevant, but I saw a difference between using nvh265dec and avdec_h265. Pipeline A: filesrc location=4K.mkv ! matroskademux ! h265parse ! avdec_h265 ! d3d11videosink Pipeline B: filesrc location=4K.mkv ! matroskademux ! h265parse ! nvh265dec ! d3d11videosink Pipeline C: same as B just glimagesink at the end (I tried with queue or videorate elements as well and the end result was basically the same.) <img src="http://gstreamer-devel.966125.n4.nabble.com/file/t379221/PTS_comparison.png" border="0" alt="Fig.1 PTS values in logged order on videosink/sink"/> First I logged each received buffers' PTS time on the videosink's sink pad for each of the pipelines. The PTS values are plotted as received. In the avdec_h265 pipeline, PTS increase frame-to-frame with a constant dPTS (difference), whereas in the other two pipelines every 3rd buffer shares the same PTS with the one before. Pipelines B and C are essentially the same. <img src="http://gstreamer-devel.966125.n4.nabble.com/file/t379221/PTS_nvdec_pipeline.png" border="0" alt="PTS values on most pads in nvdec pipeline"/> The 2nd image shows plots of PTS values logged from relevant pads in pipeline B, i.e. using nvh265dec, sorted in increasing order. Sorting was necessary as the decoder and parser elements didn't receive buffers in order; I can show the data without sorting if that's more informative. In this playback, the timings were somewhat different than on figure 1. It seems that the parser (h265parse) outputs different PTS values than it receives. I'm not showing the data for pipeline A, but in that case PTS values did not change between elements - all looked like the plot for parser-sink here. Without a deep understanding, just looking at these numbers, I suspect that playback is choppy because of the uneven PTS increments. PTS timings don't change in pipeline A, whereas when h265parse is followed by nvh265dec, modified PTS values with uneven gradation appear from the parser's sink pad onwards. <hr align="left" width="300" /> Sent from the <a href="http://gstreamer-devel.966125.n4.nabble.com/">GStreamer-devel mailing list archive</a> at Nabble.com.