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.
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.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
