Quoting Julien MOUTTE: > > Hi Denis and others, > > As agreed during our discussion in FOSDEM i m sending this feature > request. > > In the GStreamer sink element i need to be able to handle 2 cases : > > - Instantiated with nothing initialized on the DirectFB Side. then i > init, get primary layer and draw fullscreen in a window i create myself.
"fullscreen in a window" means a window covering the whole screen? > - Applications passes a precreated window where i should draw. Why not just pass the surface to the plugin? That would of course not be enough for using the overlay keyed to a window, or using other layers at all. > I will create an interface for that with something like : > > gst_dfb_overlay_set_window (GstDfbOverlay *overlay, IDirectFBWindow > *window) > > From that window i would need to retreive supported pixel format > (hardware) to inform gstreamer how to get optimal and cheap colorspace > conversion. And i also need to be able to set the pixelformat of the > window's surface after creation when the pipeline capabilities have been > negotiated. While I'm thinking that IDirectFBSurface::SetDescription() would require a lot of checks if the description could be applied, another simpler method IDirectFBSurface::SetPixelFormat() could be done much easier. What about choosing the right surface size? Using a surface with the original video content size would save scaling, too (in addition to saving color space conversion). Scaled windows will be added soon. For now you should create an intermediate surface within the plugin (with best size and format) and Blit or StretchBlit from that, unless you are using direct decoding into a layer's surface, of course. Greetings! -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
