Le jeudi 9 février 2012 23:34:14, Dan Dennedy a écrit : > On Thu, Feb 9, 2012 at 1:03 PM, Christophe Thommeret <hf...@free.fr> wrote: > > Hi Dan, > > > > I can now run "melt -consumer qgl clip.xxx" > > In this case, glsl.csc is created instead of avcolor_space. > > It does rgb24/rgb24a/yuv420p/yuv422 to gl texture. > > It calls > > mlt_frame_set_image( frame, (uint8_t*)dest, > > sizeof(struct glsl_texture_s), g->texture_destructor ); > > > > and sets "format" to mlt_image_glsl. > > why not the existing mlt_image_opengl? There are some legacy cases of > code doing something with mlt_image_opengl treating it the same as > mlt_image_rgb24a, but we can clean that up or switch to it later.
I wasn't sure what mlt_image_opengl was for. So i went for _glsl, also thinking that if later MLT gets opencl support, the names might be confusing. But that's not a big deal to change to something other. > > then the qgl consumer (a QGLWidget) displays dest->texture. > > I think something like QGLWidget really belongs more in a Qt app than > MLT. Also, then the app has more flexibility in choosing a audio-only > consumer, but if it makes it dev easier by simply working with melt, I > understand. Exactly, i need an easy way to test, so writting a consumer (very basic, no audio, fixed ~25fps) was much easier than porting something like kdenlive :) > > This works well for yuv422 and rgb24, but it never gets yuv420p, all > > yuv420 > > If you have an image conversion filter properly applied (see > core/producer_loader.c), then you can get yuv420p by using > mlt_frame_get_image() but not by directly accessing the properties. > However, you seem to be mucking around with the image converters and > maybe screwed up something. How did you do "glsl.csc is created > instead of avcolor_space?" If you are replacing an image converter > (avcolor_space is an image converter), then it is your responsibility > to convert from whatever to yuv420. I've modified producer_loader_init to create glsl.csc when the consumer sets the global_property data "glsl_env" (a pointer to an instance of a class(well, a struct) that contains everything needed by filters, creating/caching fbo, textures and shaders, locking the gl context (a context can only be made current in one thread at any time), etc...) > > streams are converted somewhere (i guess the producer) to yuv422 before > > reaching the csc filter. Is there any way to disable this initial > > conversion ? > > The producer is not required to give you what you ask for. For > example, image-based producers generally always give rgb24 or rgb24a. > Hence, the image converter is there to convert it for the > mlt_frame_get_image() caller. However, the avformat producer does > generally give you what you ask for. The video thread calls : mlt_image_format vfmt = mlt_image_glsl; int width = 0, height = 0; uint8_t *image; mlt_frame_get_image( frame, &image, &vfmt, &width, &height, 0 ); and the converter gets yuv422. > Note also that with consumer.real_time <> 0 there is a thread running > to pre-render frames, and that thread defaults to mlt_image_yuv422, > but you can change it by setting property mlt_image_format=yuv420p on > the consumer (added since last release). I'm running with the default real_time=1. Could you tell me more about setting this consumer' format property ? > > Not only i could validate the yuv420p_to_glsl code but it would also > > minimize a bit the amount of data to upload. > > > > (Note : normalisers are disabled.) > > > > -- > > Christophe Thommeret -- Christophe Thommeret ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
