GNOME Bugzilla – Bug 742879
validate: Timestamp range check rarely right
Last modified: 2018-11-03 11:06:05 UTC
Validate makes warning about timestamp out of range that seems a little buggy. Here's an example. Description : a buffer leaving an element should have its timestamps in the range of the received buffers timestamps. i.e. If an element received buffers with timestamps from 0s to 10s, it can't push a buffer with with a 11s timestamp, because it doesn't have data for that There exist a lot of cases where this isn't true. In the case of mad I have not made any investigation. But I can think of many reason this warning may fail. Input buffer may have no timestamp (hopefully this is already handled), buffer may have no duration, and decoded data may be produce in smaller chunk. The input buffer could have an estimated position and duration, and decoder fixes it. In case of H264 with B-Frames, this is also wrong if input timestamp are DTS only, while output is PTS only. This would be like comparing orange with apples. I haven't had time to check the code yet, but most likely that we should have a set of checks for which we cause this check to not trigger.
In the h.264 decoder case, incoming DTS should match output PTS exactly I think.
(In reply to comment #1) > In the h.264 decoder case, incoming DTS should match output PTS exactly I > think. PTS are often shifted forward of N frames. In most case they will be in range, except when the stream is drained.
-- 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-devtools/issues/8.