[MPlayer-cvslog] r18593 - trunk/libmpcodecs/vf_mcdeint.c

michael subversion at mplayerhq.hu
Tue Jun 6 12:34:46 CEST 2006


Author: michael
Date: Tue Jun  6 12:34:45 2006
New Revision: 18593

Modified:
   trunk/libmpcodecs/vf_mcdeint.c

Log:
known issues and notes


Modified: trunk/libmpcodecs/vf_mcdeint.c
==============================================================================
--- trunk/libmpcodecs/vf_mcdeint.c	(original)
+++ trunk/libmpcodecs/vf_mcdeint.c	Tue Jun  6 12:34:45 2006
@@ -16,6 +16,33 @@
     Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
 */
 
+
+/*
+Known Issues:
+* The motion estimation is somewhat at the mercy of the input, if the input
+  frames are created purely based on spatial interpolation then for example
+  a thin black line or another random and not interpolateable pattern
+  will cause problems
+  Note: completly ignoring the "unavailable" lines during motion estimation 
+  didnt look any better, so the most obvious solution would be to improve
+  tfields or penalize problematic motion vectors ...
+
+* If non iterative ME is used then snow currently ignores the OBMC window
+  and as a result sometimes creates artifacts
+
+* only past frames are used, we should ideally use future frames too, something
+  like filtering the whole movie in forward and then backward direction seems 
+  like a interresting idea but the current filter framework is FAR from
+  supporting such things
+
+* combining the motion compensated image with the input image also isnt
+  as trivial as it seems, simple blindly taking even lines from one and
+  odd ones from the other doesnt work at all as ME/MC sometimes simple
+  has nothing in the previous frames which matches the current, the current
+  algo has been found by trial and error and almost certainly can be
+  improved ...
+*/
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>



More information about the MPlayer-cvslog mailing list