[gst-devel] XOverlay issue

Zeeshan Ali zeenix at gmail.com
Tue Nov 9 07:45:04 CET 2004

  Many people are anxious to see caca/aasink to be embeddable, but as
I said on the IRC that doing this by making caca/aasink implement the
xoverlay interface would make those sinks X-specific. The reason sam
(the author of libcaca) didn't provide support for embedding uptill
now is because he didn't want his lib. to have any X-specific API. I
would also advice against making these elements X-specific. So I was
thinking of what could be done to be able to embed these elements and
remain x-independent. I could think of the following two
1. Have another Generic interface, lets name it GstGenericOverlay
(GstOverlay has already been taken). The x-specific videosinks would
continue to implement xoverlay but non-x-specific videosinks would
implement this interface. It would be just like it's X brother, except
for the following x-specific stuff:

void gst_x_overlay_set_xwindow_id (GstXOverlay *overlay, gulong xwindow_id);
void gst_x_overlay_got_xwindow_id (GstXOverlay *overlay, gulong xwindow_id);

  Instead GstGenericOverlay would have something like:

void gst_generic_overlay_set_buffer (GstGenericOverlay *overlay,
GstBuffer *buffer);

   The application can simply tell the sink where to render and there
wouldn't remain any need to actually do any kind of embedding.

2. We can have caca/aa filter elements along side the existing sink
elements. This way the app. can use any sink (embeddable or not) to
display the rendered output from these libs.

  I personally like solution#2. Please let me know which one of these
solutions you people like or if anyone have a better solution in mind.

"All over the place, from the popular culture to the propaganda
system, there is a constant pressure to make people feel that they are
helpless, that the only role they can have is to ratify decisions and
to consume." -- Noam Chomsky

More information about the gstreamer-devel mailing list