After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 742879 - validate: Timestamp range check rarely right
validate: Timestamp range check rarely right
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-devtools
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-01-13 18:43 UTC by Nicolas Dufresne (ndufresne)
Modified: 2018-11-03 11:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicolas Dufresne (ndufresne) 2015-01-13 18:43:28 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.
Comment 1 Olivier Crête 2015-01-13 19:15:31 UTC
In the h.264 decoder case, incoming DTS should match output PTS exactly I think.
Comment 2 Nicolas Dufresne (ndufresne) 2015-01-13 19:48:20 UTC
(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.
Comment 3 GStreamer system administrator 2018-11-03 11:06:05 UTC
-- 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.