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

[Martin Soto]

On Wed, 2004-03-10 at 23:57, Ronald S. Bultje wrote:
> On Thu, 2004-03-11 at 00:12, Martin Soto wrote:
> > I've been hacking the stuff heavily in the last days, so I thought I may
> > try to explain what I understand of it at the moment.
> [..]
> 
> Great! Thanks! Things got a lot clearer. When using basicgthread (the
> last remaining sync bug is opt-related), I have no more sync issues!
> 
> Would you mind copying this to gstreamer/docs/pwg/advanced-clock.xml so
> other people can enjoy this story, too?

Yeah, I'll do it as soon as I have CVS access (it's already requested).

> Can't the discont event contain (or request) a reference to the handler
> element? I.e. gst_event_discont_get_value (GstEvent *event, Gstformat
> fmt, gint64 *value, GstElement *caller);. Ugly, but it'd work. 

I'm not sure I understand how this would help. It doesn't help the event
to know who is receiving it. It is the clock that has to know who is
adjusting its time. So we'd need to extend the clock's API for that
purpose, but if we're going to do it, we'd rather add the serial
numbers.

> It only
> requires that demuxers send out the same event (refcounted, of course)
> to all their sink pads. I think all demuxers already do this.

Hmm, no, it's just the opposite, I guess. When implementing dvddemux, I
noticed that mpegdemux actually creates a new discont event for every
pad. I wondered if that was sort of a bug in mpegdemux and checked
around only to find that other demuxers do the same (admittedly I didn't
check all of them). I thought it was necessary for some obscure reason
and proceeded to implement dvddemux the same way. Is there actually a
reason for doing that? Would it be ok to start changing demuxers to just
refcount and forward disconts?

My general idea would be as follows:

1. Change gst_event_new_discontinuous to internally generate a serial
number and store it in the event.

2. Add a new gst_event_discont_get_serial function to allow retrieving
the serial number.

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.

4. Add a new gst_element_set_time_serial (once again your naming
suggestions will be greatly appreciated) that receives a serial number
and a time, and sets the element time based on the corresponding clock
event time.

As far as I can see, these are all backwards compatible changes. In
order for this new infrastructure to work in general, however, we need
two things:

- Elements forwarding discontinuities must just refcount discont events
properly and forward them. Elements creating new discont events should
create one event and send it properly refcounted to all output pads.

- Sink elements must handle disconts somewhat differently:

  case GST_EVENT_DISCONTINUOUS:
    {
      GstClockTime time;
	      
      if (gst_event_discont_get_value (event, GST_FORMAT_TIME, &time)) {
        gst_element_set_time_serial (GST_ELEMENT (sink), time,
            gst_event_discont_get_serial (event));
      }
    }

As stated, is it possible to keep the existing behavior working in order
not to break the ABI.

Any objections against me implementing this?

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