[gst-devel] Losing prerolled buffers

[Thomas Vander Stichele]

Hi,


> Firstly with my custom sink[1] (derived from GstBaseSink) I get the
> following warning.
> 
> Message: Internal data flow problem.
> Debug: gstbasesink.c(1878): gst_base_sink_chain_unlocked ():
> /marlinloadpipeline0/load-sink-0:
> Received buffer without a new-segment. Assuming timestamps start from 0.
> 
> what element should be responsible for creating/sending the
> new-segment?

In vague terms, "any upstream element".  To be more concrete, the source
element should definately be sending one, and then other elements
downstream could conceivably catch it and transmogrify it.  The purpose
of the new segment event is to tell the rest of the pipeline more things
about the data flow that it's going to send from that on; for example,
which is the important data and which should be ignored (by giving a
data range in time or bytes, ie the "segment"), what speed it should
play at, ...


>  The element the sink is linked to (my
> channel-splitter[2]) is just passing any events it receives onwards.
> 
> 	if (GST_IS_EVENT (buffer)) {
> 		for (p = splitter->srcpads; p; p = p->next) {
> 			gst_pad_event_default (GST_PAD (p->data),
> 					       GST_EVENT (buffer));
> 		}
> 		g_object_unref (splitter);
> 		return GST_FLOW_OK;
> 	}

If this is in your _chain function - events are now handled in a
specific sink_event function instead.

> Secondly:
> With my pipeline[3] I seem to be losing the first buffers between the
> splitter and the sink, but only sometimes. Sometimes all the buffers
> make it across, sometimes none. Usually some of them do get across.
> This is the output from a test-program[4]

There's a lot of unknowns to answer the question just by looking at
code.  For example, does your channel splitter's signal callback get
fired from the streaming thread ? If it doesn't, your streaming thread
may happily be pushing buffers over the cliff like lemmings before you
link something to the pad.  Just an example of course.

If I were you, I"d be adding some g_print's to my chain functions to see
timestamps and hence see where it starts going wrong.

Thomas