Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gstreamer gstreamer
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 930
    • Issues 930
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 444
    • Merge requests 444
  • 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
  • gstreamergstreamer
  • Issues
  • #276
Closed
Open
Issue created Feb 19, 2018 by Bugzilla Migration User@bugzilla-migration

aggregator: flushing state never resets with a tee

Submitted by Florian Zwoch @fzwoch

Link to original bug (#793607)

Description

Actually I noticed with 1.12.4 - But looking at the code makes me belief this affects 1.13.x as well.

I'm not 100% sure how flushing works in detail, so maybe help me out here. But I made an element based on GstAggregator and it works just fine so far. I noticed that seeking is broken when I attach a tee element downstream to the aggregator.

The basic use case is to listen on the bus for an EOS, and then seeking back to the start (with flushing). But I think it also happened when I tried a regular seek while in PAUSED.

The result is that the aggregator is processing data just fine but does not output any more data after the first seek.

A little bit of tracing lead me to this code:

(gstaggregator.c:1985)
if (flush) {
priv->pending_flush_start = TRUE;
priv->flush_seeking = TRUE;
}

[..]

(gstaggregator.c:2004)
if (!evdata.result || !evdata.one_actually_seeked) {
GST_OBJECT_LOCK (self);
priv->flush_seeking = FALSE;
priv->pending_flush_start = FALSE;
GST_OBJECT_UNLOCK (self);
}

So when I have a tee downstream I do get two seek events (correct?). The first one seems to work just fine - the second one however has much less debug log (not doing any flushing?).

Basically the second seek was a success (evdata.result == 1) but I think evdata.one_actually_seeked was also 1 because after that point I kept hitting this:

(gstaggregator.c:555)
GST_INFO_OBJECT (self, "Not pushing (active: %i, flushing: %i)",
self->priv->flush_seeking, gst_pad_is_active (self->srcpad));

with "active: 1, flushing: 1". Which indicates that "priv->flush_seeking = FALSE;" was not hit again, leaving its state in flush_seeking.

To verify I boldly moved the "priv->flush_seeking = FALSE;" line out of the brackets so it gets set regardless of the results and it did "fix" my original problem.

Surely this is not the correct fix, but maybe your understanding is much better and you already have an idea what may cause this behavior in case a tee is present downstream?

I can attach some traces for this particular case - just lacking access to the right machine.

Version: 1.13.1

Assignee
Assign to
Time tracking