Encoder crashes due to invalid memory pointers in Joint Motion Search with Resolution Scaling

[GoogleCodeExporter]

What is the expected behavior? What do you see instead?
In joint_motion_search function Encoder crashes in either Interpolation or 
motion search module due to bad memory pointers in case of compound prediction 
with resolution change enabled. The main reason is that  the reference frame 
prediction buffer pointers, motion vectors & scaling factors were getting 
messed up in the joint motion search iterations. Reference frame buffer 
pointers & scaling factors of Non-scaled reference frames are being used 
instead of scaled reference frames along with unnecessary scaling of motion 
vectors, which were leading to bad memory pointers. 

What version are you using? On what operating system?
Version 2.3.0. Windows OS. 

Can you reproduce using the vpxdec or vpxenc tools? What command line are
you using?
Yes, you can try encoding any sequences with resolution change enabled, which 
will lead to reference frames having different resolutions from the current one 
during compound prediction. Higher resolution sequences have better chances to 
reproduce these memory crashes at the frame boundaries especially.  

Please provide any additional information below.
The fix for this would be to use pointer from the scaled reference frame which 
will be of same resolution as the current one and not additionally scale MVs. 

Original issue reported on code.google.com by ynsai...@gmail.com on 17 Mar 2015 at 8:43

[GoogleCodeExporter]

Where did you get version 2.3.0?

Have you tested with the latest HEAD from 
https://chromium.googlesource.com/webm/libvpx

Original comment by johannkoenig@google.com on 17 Mar 2015 at 6:33

[GoogleCodeExporter]

Original comment by ya...@google.com on 18 Mar 2015 at 5:52

[GoogleCodeExporter]

Do you have a test clip and command line so that we can reproduce?

joint_motion_search backs-up and replaces the non-scaled refs with scaled 
versions--in the same way that single_motion_search does--so the code is at 
least trying to do the right thing.

Original comment by agra...@google.com on 18 Mar 2015 at 7:44

[GoogleCodeExporter]

I've found a clip that demonstrates the problem. I'm taking a look at it.

Original comment by agra...@google.com on 18 Mar 2015 at 9:49

• Changed state: Started

[GoogleCodeExporter]

Fixed by the following two patches:
https://gerrit.chromium.org/gerrit/#/c/74137/
and:
https://gerrit.chromium.org/gerrit/#/c/74184/

Original comment by agra...@google.com on 20 Apr 2015 at 10:20

• Changed state: Done