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

File sources where the first timestamp is above zero are not handled properly by GES

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
Assignee
Assign to
Time tracking