Le lundi 14 novembre 2011 22:49:09, Dan Dennedy a écrit : > In general, it seems difficult and costly performance-wise to fit GPU > effects into the framework unless you use them entirely. Otherwise, > you end having to do some on the CPU and also keep the full > flexibility and expression of arbitrary filter ordering. Also, one > should consider OpenCL and how either can be combined with hwaccel > decoder output in vendor-independent VA-API, which is still not > integrated. I am not willing to lend much effort to a NVIDIA-only > solution. Also, my experience with VDPAU shows it gets tricky to keep > things stable when you combine it with multiple video tracks, > transitions, and parallel processing, which is why it is not enabled > by default.
Hi Dan, I've looked at mlt's vdpau and i see the problem. A vdp decoder maintains a bunch of internal variables that are not exposed to the user through videosurfaces, so if you can't destroy and recreate without issues. I've fixed this by removing the global g_vdpau and adding vdpDevice and vdpDecoder to producer_avformat.vdpau struct. Transitions look good now. Do you have any other reproducible bug in mind ? -- Christophe Thommeret ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
