GNOME Bugzilla – Bug 731265
h265parse: small fix for buffer time stamping
Last modified: 2018-11-03 13:23:53 UTC
Created attachment 277945 [details] [review] h265parse: add buffer timestamps This patch adds timestamps to the buffers when not provided by other elements.
Review of attachment 277945 [details] [review]: ::: gst/videoparsers/gsth265parse.c @@ +1432,3 @@ + * For now, a naive method is used below. + */ + GstClockTime dur; Declare variables at the beginning of the block @@ +1436,3 @@ + GST_LOG_OBJECT (h265parse, "duration based ts"); + /* naive method: no removal delay specified + * track upstream timestamp and provide best guess frame duration */ You could also keep the duration at GST_CLOCK_TIME_NONE for now. But does the FIXME comment above mean that we currently don't calculate the DTS but only the PTS, and still use the PTS magically as DTS? That seems wrong @@ +2062,3 @@ + (segment->start != 0 || segment->rate != 1.0 + || segment->applied_rate != 1.0)) + h265parse->do_ts = FALSE; I think you should never timestamp when receiving a TIME segment, independent of the start position, rate and applied rate
-- 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/152.