4K playback optimization help needed

[QwjN1Y9mJvamZJ]

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.)
<http://gstreamer-devel.966125.n4.nabble.com/file/t379221/PTS_comparison.png>
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.
<http://gstreamer-devel.966125.n4.nabble.com/file/t379221/PTS_nvdec_pipeline.png>
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.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200129/3f7cdfa3/attachment.htm>