GNOME Bugzilla – Bug 791202
aggregator: need gst_aggregator_pad_set_nowait() for sparse streams
Last modified: 2018-11-03 12:43:19 UTC
We need a way to tell GstAggregator to never wait for data on certain pads. This is needed for sparse inputs where we may not always get data or regular GAP events. Without this, a muxer in non-live mode will just lock up if it doesn't receive data or GAP events on one of the input pads, and in live mode we will always end up with the maximum configured latency since we'll always wait and time out. See gst_collectpads_set_waiting().
Marking as blocker for now, since it's important for porting muxers and we should really try and get it done this cycle as well.
Speaking of the hardest problem in computer science, I'd prefer if we called it something like gst_aggregator_pad_set_nowait() (ie, invert it)
> I'd prefer if we called it something like gst_aggregator_pad_set_nowait() I like it.
This isn't really a blocker.
Should this be the job of subclasses, or should we simply make use of the SPARSE flag in the stream-start events? Instead of making it a boolean, should we maybe a) wait in live mode until the deadline anyway b) wait in non-live mode until the queues of the other pads are full, or N time units difference between the to-be-output buffer and the lowest wait-pad queue fill level, or ...?
I think we should use the SPARSE flag automatically but should still allow subclasses to override that "somehow" (auto/always-wait/never-wait enum perhaps?) I don't think we should wait in live mode until the deadline anyway for sparse streams, that would defeat the point of marking them as sparse imho. If so, there would have to be a way to set a separate / possibly smaller timeout for sparse pads, otherwise you pretty much always wait for max latency with live sparse streams (where there'll likely not be any gap events), no? But maybe your questions indicate that more flexibility may be needed in future, which might points towards an enum and keeping it simple for now (never wait).
I was thinking of an enum (WAIT, NO_WAIT for now). And later there could be another function to set a wait timeout based on running time levels of other pads for example (too bad we can't have WAIT(timeout))
Opinions?
Couldn't we have `gst_aggregator_pad_set_timeout(pad, timeout)` and: - 0 means NO_TIMEOUT - CLOCK_TIME_NONE means WAIT ?
I was going to propose the same thing as Thibault just did.. But I'm not sure we have any real case for this partial timeout? Do we have any muxer where it is relevant ?
I could see a use case where one might want to wait "just a little" just to give the scheduler enough time to push through some data. Example: textoverlay waiting for subtitles on the text pad (let's ignore that we will usually get gap events there). If we have a playback pipeline that's paused and just move the slider in the movie player we ideally want to see the subtitles if they're available and produce in time. In a playback situation it wouldn't matter because if they're not put on top of this frame they'll be there for the next, but for a snapshotting pipeline or a player in paused state one might get better results if one could wait on the text pad just a little. (How much that should be I don't know.)
What I generally don't like about all no-wait situations is that it is completely undeterministic if it waits long enough or not, it only depends on the scheduler in the end. I wonder if we couldn't do something else here that does not feel like a hack. Why are the GAP events (and live pipeline deadlines) not enough to let sparse streams advance btw? When can't we produce regular GAP events?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/259.