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
  • #514
Closed
Open
Issue created Nov 05, 2018 by Jacob Foytik@jfoytik

matroskademux : can no longer seek right after the no-more-pads signal

We have a custom gstreamer plugin that uses matroskademux internally and requires the demux element to seek as soon as it can. We are currently handling this by performing the seek immediately after we receive the 'no-more-pads' signal from matroskademux. It appears this behavior is no longer supported (in v1.14.4) since changes related to this enhancement..

It was my understanding that if the element was in the PAUSED state and all of its pads were created, then it was safe to seek on the element. If this is not the case, what is the best method for finding the earliest time to seek on an element?

Assignee
Assign to
Time tracking