Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gst-plugins-good gst-plugins-good
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 646
    • Issues 646
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 71
    • Merge requests 71
  • 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-plugins-goodgst-plugins-good
  • Issues
  • #734
Closed
Open
Issue created May 21, 2020 by David Ing@ding

qtdemux: Wrong first buffer running time with a certain file

With video the first outputted video frame running time is at 0.5sec, it should be at 0. More details in the comments.


I am using Gstreamer 1.16.1.

Suppose I have a video file where the first frame has a timestamp of 0.1 seconds, and the last frame has a timestamp of 1.1 seconds. For this file, GstDiscoverer correctly reports the duration to be 1.0 seconds.

If I create a GESClip for the file, say with an inpoint at 0, then the first 0.1 seconds of the composition is blank (because there were no frames in the source file until the timestamp at 0.1). This behavior is correct.

If my clip is intended to play for a time which takes it past the timestamp at 1.0, then the clip cannot be added to the layer because timeline_tree_can_move_element will say that the clip is invalid in some way. The function timeline_tree_can_move_element seems to be assuming that the maximum timestamp in the source file is the same thing as the duration of the source file, but this is not true for files where the earliest timestamp is above zero.

The faulty logic seems to be in here:

  • timeline_tree_can_move_element
  • check_track_elements_overlaps_and_values
Edited May 22, 2020 by Thibault Saunier
Assignee
Assign to
Time tracking