[gst-devel] gst-python and GstXOverlay

Martin Soto soto at informatik.uni-kl.de
Wed Nov 10 03:43:08 CET 2004

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.


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

More information about the gstreamer-devel mailing list