On Mon, Nov 23, 2015 at 03:54:19PM +0100, Michael Niedermayer wrote: > On Mon, Nov 23, 2015 at 11:01:02AM +0100, Clément Bœsch wrote: > > On Sun, Nov 22, 2015 at 04:27:02PM +0100, Michael Niedermayer wrote: > > [...] > > > > > IIUC src_x/y are only an approximation, as the exact motion vector > > > > > isnt an integer in fullpel units so it would be mostly cosmetic > > > > > if x + 4 >> 8, or /8 is used > > > > > > > > yes > > > > > > > > mpeg used x >> n, i replaced with x / (1<<n), but i could switch back to > > > > the original shift, or even do x+(1<<(n-1))>>n if you want some > > > > rounding. > > > > > > > > same for snow... what would you prefer? i have no real opinion, this > > > > code > > > > doesn't interfere with normal decoding anyway (so performance is less > > > > relevant) > > > > > > i really dont know, i think something mostly symmetrical should be > > > preferred so that for visualization the vectors arent biased in > > > some direction > > > thus a plain >> 3 might be bad > > > > > > > So I kept the division, but hardcoded the 8 in snow. > > > > Applied, thanks > > > > BTW: can't we get more information on the "direction" (that is, the source > > ref) for h264? Currently in the mpegvideo code, we have two ref possible > > (forward and backward), but h264 (and maybe other similar codecs sharing > > that code) can pick from more refs, right? > > yes >
where can this information be obtained? -- Clément B.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
