[Bug 757563] audiomixer: issues with seamless looping (missing support for non-flushing seeks)

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=757563

--- Comment #9 from Stefan Sauer (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> ---
(In reply to Mathieu Duponchelle from comment #8)
> Review of attachment 362753 [details] [review]:
> 
> Just gave a quick look, I'll try to give a more in-depth asap, at least on
> the aggregator side :)
> 
> ::: gst-libs/gst/base/gstaggregator.c
> @@ +1567,3 @@
> +
> +        /* send whatever is in the mix buffer */
> +        gst_aggregator_drain (self);
> 
> This should be done from the aggregate (srcpad) thread, not from a random
> sinkpad's streaming thread :)

I know. That's why it is done in
gst_aggregator_default_sink_event(), which is called from
gst_aggregator_do_events_and_queries(), which is called from
gst_aggregator_aggregate_func() and thats the src-pad task.

> 
> @@ +2140,3 @@
> +  priv->segmented_seeking = segmented;
> +  /* we apply the segment, once we have segment from all sources */
> +  /* FIXME: do we need a queue of seek-events? */
> 
> If I understood what you told me at the conf correctly, yes ?

That's why there is a FIXME: - I am still pondering whats the best way to do
this. We'll basically need a GQueue for sequence numbers (guint32) on the
aggregator and on each sink-pad.
1) we get a seek on src, if segmented push seq_num to aggregator queue and each
sink-pad queue
2) we get a segment on a sink-pad
   2.1) check that ev.seq_num == queue.head.seq_num
   2.2) pop the seq_num off the pad_queue
   2.3) if none of the sink-pad queues has the aggregator-queue.head.seq_num at
head, do the seek and pop the seq_num from the aggregator queue, the seek is
done

This sounds somewhat involved and not cheap.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.