2012/2/16 Maksym Veremeyenko <ve...@m1stereo.tv>: > 16.02.12 18:54, Dan Dennedy написав(ла): > >> 2012/2/16 Maksym Veremeyenko<ve...@m1stereo.tv>: >>> >>> 15.02.12 20:49, Dan Dennedy написав(ла): >>> >>>> 2012/2/14 Maksym Veremeyenko<ve...@m1stereo.tv>: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> data for overlay image converted from RGBA to YUV422 for each frame. >>>>> attached patch save converted image of *pixbuf* producer to avoid >>>>> converting >>>>> it to profile format each time it require to produce resulting frame. >>>>> >>>>> with that patch and previous SSE2 patches it possible to put full hd >>>>> logo >>>>> on >>>>> video without dropped frame. >>>>> >>>>> it is draft version with leak on exit but it could answer the question >>>>> if >>>>> it >>>>> is a right approach for solving problem with image converted to desired >>>>> format once per frame instead of once per load/format_change. >>>> >>>> >>>> >>>> The idea is fine but not the patches. The first patch to mlt_frame is >>>> rejected because they are not really needed; use >>>> mlt_frame_get_alpha_mask and mlt_frame_get_image. API changes >>>> including additions are not taken lightly and need strong >>>> justification. These two just add confusion. >>> >>> >>> problem is *mlt_frame_get_alpha_mask* function that generate fake alpha >>> channel for frames without one. I had a plans to propose drop creating >>> filled alpha plane with it function and just return NULL, but in the same >> >> >> That is a high impact change that requires analyzing every call to the >> function, and fixing and testing its impact. > > if you decide to break API that will be a good chance to implement that > feature and fix possible regression caused by that improvement...
but it is a low priority for me, and I do not see the considerable gain it would provide, but feel free to clarify >>> time fix compositing function to care about 8 variants of alpha_a, >>> alpha_b, >>> weight values... >>> >>> i'll have a look on mlt_frame_get_image... >>> >>> >>>> >>>> In the pixbuf patch, you should not call the convert_image virtual >>>> function directly; use mlt_frame_get_image(). Unfortunately, >>>> mlt_frame_set_image lacks a format parameter. I forget why. For now, >>>> just set the format property. mlt_frame_get_alpha_mask() should >>>> probably have an out param. I will think about breaking API because >>>> there are other API changes coming in this release. For now, you will >>>> have to use a computed size for the alpha. Lastly, break clone.size >>>> apart into clone.image_size and clone.alpha_size for readability. >>>> >>> >>> such code could be added to pango and possibly other producers. May be it >>> possible to provide another way for storing/cached converted/scaled >>> images >>> on upper level... >> >> >> I thought about that, and it makes some sense. The upper level does >> not understand when the image changes - only the producer knows this. >> Of course, the producer could set a flag to indicate the image changed >> or fire an event that causes the caching mechanism to flush. I will >> think about it more. >> > what if after receiving frame consumer makes a clone with all properties and > during requesting new frame sent it back, so all filters and producer could > check if frame need to be updated... A filter or transition can already indicate if it needs to do something by choosing whether to push its get_image function pointer onto a stack on the frame. Producers also push get_image onto the frame's stack, but they need pretty much to do this for every frame to define the frame's image. Perhaps a change to mlt_producer can repeat the previous frame's image if the actual producer did not put get_image on the stack. Some property of the producer could choose the behavior since things like the mlt_playlist producer support "blank" items and theoretically so could a regular producer. Also, avformat producer has caching based on position. Maybe that can be generalized and used for this purpose, but I think it does not make sense for some live sources. OTOH, decklink producer is a live source and now does position-based caching to support yadif deinterlace and framerate adaption. Needs more thinking through, but I think we are getting close to something general. -- +-DRD-+ ------------------------------------------------------------------------------ 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
