Created attachment 95076 [details] [review]
gather and relay events

first attempt:
 gsttee.c |  128 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
 gsttee.h |    5 ++
 2 files changed, 124 insertions(+), 9 deletions(-)

Hi,
code contains :

tee->have_events &= TRUE;
...
  tee->have_events = FALSE;

But have_events is never initialised to TRUE, so tee->have_events &= TRUE is always FALSE. Am i wrong ?

Created attachment 97487 [details] [review]
gather and relay events

oops, your right. Corrected patch here.

We have some problems with this patch for this kind of pipeline :
... ! tee ! someElements ! videorate ! ...

The videorate (and someElements)  are dynamically connected to the tee, when connected the videorate sends a burst of frames, i thought it was a bug inside videorate (comments inside http://bugzilla.gnome.org/show_bug.cgi?id=435633), but does not seem to be one.

Shouldn't the start time of the newsegment sent when connecting a pad set to the same value as the position time ?

Probably yes, does it then work for you?

Created attachment 110993 [details] [review]
adds declarations to .h

This patch is an update to the previous one, but it declares the variables in the .h file (fixing compilation errors)

Adding myself to CC list

This patch alleviates the problem experience in bug #539200 and it looks fine to me, it should probably be merged.

Created attachment 113149 [details] [review]
Copy taglist when creating events

After a bit more testing, I found a problem. I'm attaching a slighly updated patch that makes a copy of the taglist before creating a new event with it since they're not refcounted.

Created attachment 113150 [details] [review]
Same patch, less trailing whitespace

Created attachment 114460 [details] [review]
Same patch with new segment start time update

The new segment for newly added pad has start time of first buffer timestamp.
When using videorate behind the tee, the videorate outputs as much buffers as nessary to cope with first buffer timestamp. i.e. if videorate has a first buffer with ts=5s, it will output 5s of buffers...
This patch fixes it, but maybe videorate should be fixed instead.
What do you think ?

The fact that videorate is broken with live pipelines and stuff like that is, imho, unrelated to this problem.

Created attachment 115489 [details] [review]
remaining patch for the segment relaying

Created attachment 115495 [details] [review]
full patch once again

Status que is that we need to
* define for what tags should be used and whats the lifetime of them
* decide therefore if we want to clear cashed tags on flush_stop
* decide wheter  demuxers resent tags after a flush_stop then too

+1 for demuxers resending tags after flush(_stop) (e.g. flushing seek).
Consider a typical transmuxing/coding scenario that uses partial pipeline prerolling as described in design/part-block (i.e. blocking on some pads followed by a flushing seek to a new position).  It is likely that tags may have been on their way and have gotten flushed (from intermediate queues), and would therefore never be heard from again if not resent.  So a partial transcode ends up without e.g. language tags whereas a complete transcode does have them.

In a similar consistent sense, this would probably mean clearing cached tags after a flush(_stop) (in present context), since:
- (roughly) so do other elements, e.g. queue
- it gives the outside (application) some measure of say in lifetime if desired
(e.g. by whether or not using flushing seek)

To extend on Mark's comment (with which I totally agree) : it's the kind of thing absolutely needed for proper seek/tag/event handling in gnonlin.

If we had GstBaseDemuxer (sic) we could have convenience methods for:
* getting/storing global tags
* getting/storing stream-specific tags

When storing tags, they would be emitted straight away as messages, but if no segment has been started yet (globally or on specific pads), they are stored. Then when _loop/_chain starts outputting the newsegment, it can then check to send if there are any pending tags and send them then.

Hi, Stefan, Could you update the patch for latest release.
We use it for new segments relaying. It would be nice for patch to be commited, even if not *all* events are relayed.

I was quite fine with both ways like how it handled tags and segments, better that the current behaviour anyway. but now there is quite a disagreement. I have dropped the patch for now.

Okay, lets ignore tags for now. Woule the segment side of the patch be acceptable?

This is fixed in 0.11 now with the sticky events. Do we still want to fix it in 0.10?

I gave up on it as nobody commented on the approach anyway. Please reopen if anyone still cares. Slomo, please close as WONTFIX and tell which events are sticky in 0.11.

All synchronized downstream-only events currently, i.e. caps, segment, tag, buffersize, sink-message and eos. They will be kept on pads and will only be replaced by new events of the same type* or when deactivating the pad. They will automatically be sent downstream from srcpads to their peer sinkpad after linking the pads but elements have to send them manually from their srcpad to their sinkpads (I've changed tee and others to do that in 0.11 already).

* segment events contain all segment state now, there's no accumulation necessary anymore