On Sun, Aug 19, 2012 at 01:59:41PM +0600, Mashiat Sarker Shakkhar wrote: > On 8/19/2012 12:07 AM, Kostya Shishkov wrote: > >On Sat, Aug 18, 2012 at 11:25:54PM +0600, Mashiat Sarker Shakkhar wrote: > >>On 8/18/2012 11:13 PM, Kostya Shishkov wrote: > >>[...] > >>>Maybe the same thing (chroma MV pullback) happens? Please investigate and > >>>update the log message. "I just apply some magic and it works" sounds > >>>wrong in > >>>commit. > >> > >>It's not magic. We have already discussed this. Sometimes chroma MVs > >>require edge emulation while luma MVs don't. I don't know under what > >>exact circumstances it happens, but so far I have only seen HPEL > >>pictures trigger this issue. Can you elaborate what do you want me > >>to investigate here? Because I can see that the motion vectors (both > >>chroma and luma) are fine. > > > >It hapened because luma MV=0,0, chroma MV was the same too but after pullback > >it became -1,0. So luma does not need MC in this case but chroma does. With > >bicubic interpolation that issue was masked (s->mspel = 1 triggered edge > >emulation for such cases). So please check if it's similar (chroma needing > >edge emu but luma not). > > In short, yes. It's not similar, it's just more of the same. Let me > try to explain with an example. The following log messages come > directly from avconv output (in my dev branch): > > [vc1 @ 0x439d0a0] mv_x = 26, mv_y = 2, f = 1 > [vc1 @ 0x439d0a0] Bits may have been read. (0 bits) > [vc1 @ 0x439d0a0] * UVMX = 26, UVMY = 2 > [vc1 @ 0x439d0a0] FDMV MV_X = 26, MV_Y = 0, UVMX = 13, UVMY = -1 > [vc1 @ 0x439d0a0] setting ref to last picture ... > [vc1 @ 0x439d0a0] src_x = 1574, src_y = 0, uvsrc_x = 787, uvsrc_y = -1 > [vc1 @ 0x439d0a0] selecting bottom field as source ... > ==11303== Invalid read of size 8 > ==11303== at 0x84B4A9A: ??? (h264_chromamc.asm:658) > ==11303== Address 0x495d853 is 13 bytes before a block of size 40 free'd > > The macroblock in question belongs to top field. Note that the > motion vector points to bottom field (f == 1). Hence the chroma MV, > calculated from luma, does the same. During motion compensation, > both are "pulled-up" (not sure if that's the right phrase). > Post-PullBk MVs are the ones on line 4 (FDMV ...). > > I think it has something to do with the way chroma MVs are > calculated from luma MVs with a strange rounding, i.e. > > uvmx = (mx + ((mx & 3) == 3)) >> 1; > uvmy = (my + ((my & 3) == 3)) >> 1; > > I for one would expect a proper rounding to look like: > uvmx = (mx + ((mx & 3) >= 2)) >> 1; > > Point out if I am wrong.
They have strange roundings all around. In this case it doesn't matter though because you cannot get uvmy = -1 from mv_y = 0 with this rounding. This it must come from field MV adjusting. > On top of that, the only sample I have which triggers this situation > is an HPEL sample (MVs are signaled with half-pel precision). All > three of these factors probably added up to cause the above > segfault. > > It makes me feel that the change in horizontal condition may be > superfluous. Only vertical may be enough. Let me know what you > think. It seems so. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
