After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 308042 - adder: doesn't forward upstream events to all sources
adder: doesn't forward upstream events to all sources
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.8.9
Other All
: Normal normal
: 0.10.9
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-06-17 09:29 UTC by Dominique Würtz
Modified: 2006-07-16 11:21 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
FIX: adds event callback to src pad (1.58 KB, patch)
2005-06-17 09:31 UTC, Dominique Würtz
none Details | Review

Description Dominique Würtz 2005-06-17 09:29:36 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:
Comment 1 Dominique Würtz 2005-06-17 09:31:20 UTC
Created attachment 47891 [details] [review]
FIX: adds event callback to src pad
Comment 2 Ronald Bultje 2005-07-01 17:43:49 UTC
Is this the intended behaviour? I mean, why would you seek on a series of
sources? Who do you seek to? Relative to what?
Comment 3 Dominique Würtz 2005-07-01 18:32:13 UTC
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?
Comment 4 Ronald Bultje 2005-07-02 08:58:14 UTC
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?
Comment 5 Thomas Vander Stichele 2005-07-06 09:52:11 UTC
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.
Comment 6 Ronald Bultje 2005-07-11 12:56:14 UTC
Setting to NEEDINFO until there is some better definition for that... Without,
I'd vote to keep the current behaviour of not seeking...
Comment 7 Wim Taymans 2006-07-16 11:21:01 UTC
Fixed in 0.10, adder does proper seeking now.