[gst-devel] gst-python and GstXOverlay

[Martin Soto]

On Tue, 2004-11-09 at 14:10, Jan Schmidt wrote: 
> I think (Ronald can correct me) that in the longer term we're looking at
> getting rid of the current_* pads and handling it using replugging
> instead, but not immediately.

IMO, the whole combination mpegparse/mpegdemux/dvddemux is a mess. It
needs serious refactoring. It is good to know that you guys are putting
some effort into it. 

As for replugging, I tried that alternative initially, and that was one
of the reasons I ended up writing the dvddemux element. Replugging is
hard to get right. From a scheduler point of view, it is very difficult
to guarantee that no buffers will be lost on the process (this is
especially critical for DVD playing, where a single event loss may cause
malfunctioning menus). Of course, we could try and produce an
specification of what schedulers should do with buffers "in transit"
when pads are replugged, but I think it'll be hard to avoid at least a
certain amount of nondeterminism (i.e. you don't know for sure where
buffers go).

A much more viable alternative would be to use separate switching
elements. My DVD player could be moved relatively easy to such a
solution, provided that the switching elements can be controlled by
events (i.e. it is a synchronous event running down the pipeline that
tells them which of the inputs to select). I'll probably look into that
after I solve some more urgent problems. If it works, I'll be glad to
nuke the current_* pads from dvddemux myself :-)

> aspect ratio stuff should be easier now that the pixel-aspect-ratio is
> in the caps provided to the x[v]imagesink.

Good tip, I'll look into that.

Cheers,

M. S.
-- 
Martin Soto <soto at informatik.uni-kl.de>
Universität Kaiserslautern