[gst-devel] totem and osssink? (long)

[Martin Soto]

On Thu, 2004-03-11 at 16:59, Benjamin Otte wrote:
> You can't just forward disconts, because you have to change the values stored 
> in them (the time might not change - though it can, if you use timestamp 
> rewriting elements, but most likely the default format will change. Or the 
> byte offset or whatever). So you need at least a way to copy them and send on 
> the copies.

I understand that it is not always possible to just forward discont
events, but there are cases where it is. There are also cases where you
can create a single event and push it to all of your output pads. My
point is that I have seen demuxers that just copy the events, even if
they don´t change them at all. Shouldn't we just refcount in such
situations?

> > 3. Add a new gst_clock_get_event_time_serial (feel free to suggest a
> > nicer name) that receives a serial number and returns the corresponding
> > event time. To implement this function, the clock must have an internal
> > table, associating serial numbers with event times. When a new serial
> > number is seen, the current clock time is stored, and will be returned
> > whenever the same serial number is seen again. Values will be discarded
> > from the table after a reasonable time (say, 20 seconds). Interestingly
> > enough, this makes the "snap to grid" trick unnecessary.
> > 
> Imagine using more than one clock in your pipeline (for whatever reason). It 
> doesn't work in that case. Especially not because elements generating disconts 
> most of the time have no reference to clocks (think filesrc).
> Though I'm not quite sure I understood this correctly yet.

Well, the current solution wouldn't work in that case either, since the
event time is stored in the clock.

> If you implement something that works in the general case, I'm all for it. 
> However as I said I'm not sure your idea works.

Well, it depends on how general your general case is. My claim is that
my solution is at least not worse than the current one, and may actually
make some situations better. It is still sort of a hack, but it may help
for the moment.

> But I'm very interested to review patches :)

OK, you may have some patches for review soon. For the moment, I'll try
and explain the idea again:

First the problem: When two discontinuities arrive close together, you
have a high risk of ending up with a (large) lack of sync. Consider this
example:

Time    Event                           Event Time

30s	d1 arrives to video sink	et = 30s
30.7s   d1 arrives to audio sink	et = 30s
31.5s	d2 arrives to video sink	et = 30s (!!)
32.2s	d2 arrives to audio sink	et = 32.2s

Here d1 and d2 are discontinuities. As you can see, for the second
discont event, the video sink receives event time 30s, whereas the audio
sink receives event time 32.2s.

Suppose now that all discontinuities have a unique identifier. The clock
can now associate a different event time to each identifier it sees. The
algorithm is very simple: when an id is seen for the first time, the
current time is associated to it and returned as event time. Otherwise,
the event time already associated to the id is returned. Let's look at
the example again:

Time	Event				Event Time Table

30s	d1 arrives to video sink	et[d1] = 30s
	video sink gets et = 30s
30.7s   d1 arrives to audio sink	et[d1] = 30s
	audio sink gets et = 30s
31.5s	d2 arrives to video sink	et[d1] = 30s, et[d2] = 31.5s
	video sink gets et = 31.5s
32.2s	d2 arrives to audio sink	et[d1] = 30s, et[d2] = 31.5s
	audio sink gets et = 31.5s

In this case, the clock can return the right event times because it can
differentiate between the two discontinuities.

A more complex example works as well:

Time	Event				Event Time Table

30s	d1 arrives to video sink	et[d1] = 30s
	video sink gets et = 30s
30.4s   d2 arrives to video sink	et[d1] = 30s, et[d2] = 30.4s
	video sink gets et = 30.4s
30.9s	d1 arrives to audio sink	et[d1] = 30s, et[d2] = 30.4s
	audio sink gets et = 30.0s
31.3s	d2 arrives to audio sink	et[d1] = 30s, et[d2] = 30.4s
	audio sink gets et = 30.4s

That's it. It doesn't work with two clocks, but at least it'll let me
get trigger happy with my DVD remote without my player going mad about
it.

> Though I still think an explicit syncing framework might be better. (Don't be 
> afraid of the term "framework" and that term implying "big", I use this for 
> disjoint additional parts of GStreamer, like "parsing framework" or "debugging 
> framework".)

Well, we certainly need something better. We need a way to guarantee
that all rendering sinks have enough material to play before they start
playing. Is your idea oriented in that direction? I think I'd be very
interested in reviewing some ideas ;-)

M. S.
-- 
Martin Soto <soto at informatik.uni-kl.de>