Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
gst-plugins-base
gst-plugins-base
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 631
    • Issues 631
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 103
    • Merge Requests 103
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamer
  • gst-plugins-basegst-plugins-base
  • Issues
  • #486

Closed
Open
Opened Sep 10, 2018 by Bugzilla Migration User@bugzilla-migration

decodebin3: push flush-stop event to resume multiqueue's task

Submitted by HoonHee Lee

Link to original bug (#797110)

Description

Dear All.

Deadlock seems to be happened when upstream change(e.g. dynamic stream change) and flush seeking is performed in several times in playbin3(decodebin3).

It means that

  1. auto plugging is in progress when upstream change
    and all parsepads are not exposed from parsebin.
  2. Either flush-start or flush-stop can be failed to travel to sink elements.
    Because multiqueue's sinkpad is not linked to parsebin and dropped.

As a result, muitiqueue's task is not resumed without flush-stop
and pipeline seems to be hangup.

Version: 1.14.0

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: gstreamer/gst-plugins-base#486