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

[Ronald S. Bultje]

Hi Martin,

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?

(And does anyone mind if we change the default scheduler to
basicgthread?)

> It is very difficult to work around this problem in a satisfactory
> way. The only reliable solution I can think of would be identifying
> every discont event uniquely (with a serial number, for example), and
> having a separate event time in the clock for each discont. Of
> course, older event times can be discarded after some time, so you
> wouldn't have any issues with memory usage. Xine does something like
> this as well.]

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. 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.

Btw, one of the main issues in clocking is - still - overload. Heat your
CPU to 100% and you'll see what I mean. Anyone wanna work on QoS for
0.9.x? :).

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>
Linux Video/Multimedia developer