Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gst-devtools gst-devtools
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 35
    • Issues 35
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 7
    • Merge requests 7
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamerGStreamer
  • gst-devtoolsgst-devtools
  • Issues
  • #8
Closed
Open
Issue created Jan 13, 2015 by Bugzilla Migration User@bugzilla-migration

validate: Timestamp range check rarely right

Submitted by Nicolas Dufresne @ndufresne

Link to original bug (#742879)

Description

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.

Assignee
Assign to
Time tracking