GNOME Bugzilla – Bug 308042
adder: doesn't forward upstream events to all sources
Last modified: 2006-07-16 11:21:01 UTC
Please describe the problem: Steps to reproduce: 1. build pipeline with adder source(s)->adder->sink 2. send seek event to sink 3. Actual results: source(s) won't receive event Expected results: Does this happen every time? yes Other information:
Created attachment 47891 [details] [review] FIX: adds event callback to src pad
Is this the intended behaviour? I mean, why would you seek on a series of sources? Who do you seek to? Relative to what?
Maybe I didn't understand the event/seeking system in gst correctly. My app uses a custom gstelement source (kind of a audio timeline), which is seekable. Several instances of this element get mixed together by the adder. In order to avoid having to send a seek event to each instance, I send one event to my sink (after the adder), so that this event gets forwarded upstream to the individual sources. Maybe this is the wrong way doing it?
The event implementation is correct, that's not the problem. The thing is that I'm not sure what you're seeking, since adder does not conserve timestamps from input/output streams. Rather, it'll do anything you want with it. So if I have 2 streams connected, one at 20s and one for 20m, and my timestamp is 2h in adder, what will I seek to? Your implementation currently copies the event, which may not be right, since it'd EOS all inputs right away if I seek to 1h50m. So what I'm wondering is, how should seeking be implemented in the first place?
Ronald is correct; the reason it's not forwarded is because it doesn't really have a clearly defined meaning, thus we don't allow seeking. If you can come up with a sensible interpretation for what an adder should do when it's asked to seek to a time point, let us know.
Setting to NEEDINFO until there is some better definition for that... Without, I'd vote to keep the current behaviour of not seeking...
Fixed in 0.10, adder does proper seeking now.