Mercurial > mplayer.hg
changeset 18592:500f57bf5c6f
known issues and notes
| author | michael |
|---|---|
| date | Tue, 06 Jun 2006 10:34:45 +0000 |
| parents | 7df94ee8f74a |
| children | 99a9c47040c0 |
| files | libmpcodecs/vf_mcdeint.c |
| diffstat | 1 files changed, 27 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- a/libmpcodecs/vf_mcdeint.c Tue Jun 06 08:59:05 2006 +0000 +++ b/libmpcodecs/vf_mcdeint.c Tue Jun 06 10:34:45 2006 +0000 @@ -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>