ons 2018-12-05 klockan 21:21 +0000 skrev matthew.w.fearn...@gmail.com: > > From: Matthew Fearnley <matthew.w.fearn...@gmail.com> > > The maximum allowable range for ZMBV motion estimation is [-64..63], since > the dx,dy values are each stored in the upper 7 bits of a signed char. > > (Previously, the range was capped in the code to 127, resulting in an > effective range of [-127..126]) > > Also fix a range error in the zmbv_me() for-loops ('<' instead of '<='), > which made the limit asymmetrical [-N..N-1], and also prevented it from > reaching the blocks touching the bottom/right edges. > The range is now more symmetrical [-N..N], although this requires separate > range caps of 64 and 63 for negative and positive dx,dy. > > Practically, this patch fixes graphical glitches e.g. when reencoding the > Commander Keen sample video with me_range 65 or higher: > > ffmpeg -i keen4e_000.avi -c:v zmbv -me_range 65 keen4e_me65.avi
I'd expect this problem to pop up with -me_range 64 too, no? I went over the patch, and it looks fine. But what's up with the xored logic? It seems like it would compute xored always from the bottom- right-most MV. The loop in zmbv_me() should probably have a temporary xored and only output to *xored in if(tv < bv).. /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel