• Rupert Swarbrick's avatar
    tempv_signaling: Simplify test for whether prev_frame works for mvs · 1f990a64
    Rupert Swarbrick authored
    For some background, see this previous change in Gerrit[0]. What's
    going on here is that we only want to use a previous frame for motion
    vector prediction if the encoded sizes match. When scaling with
    superres, this means the size before upscaling.
    To check this correctly, we need to check prev_frame's width/height
    and compare it with the current frame. Without superres, prev_frame's
    width/height is stored in y_crop_width/y_crop_height so we can check
    that way. With superres, those numbers are after the scaling, so can't
    be compared with cm->width and cm->height.
    The previous code worked around this by comparing with cm->last_width
    and cm->last_height. That works because these are the width/height for
    the last encoded and shown frame and that frame *is* prev_frame if
    last_show_frame is true. Since this is the only case when we want to
    use prev_frame, they are the numbers we need.
    This patch simplifies the logic by storing the width/height in
    RefCntBuffer before any scaling and then checking that they match.
    The check for whether we can use motion vectors from a previous frame
    is factored out into a pair of inline functions in the
    header. frame_might_use_prev_frame_mvs() is true if it's possible that
    this frame could use motion vectors from a previous frame. This
    doesn't use knowledge of what prev_frame is: it just checks we're not
    in error resilient mode and aren't a keyframe. When this is true, a
    flag is signaled in the bitstream to say whether we actually want to
    use motion vectors from the previous frame.
    The second function, frame_can_use_prev_frame_mvs, is true if the
    current frame / previous frame pair is suitable for sharing motion
    vectors. This is a stricter test: the previous frame needs to be
    have been shown and not to have been intra_only, and it needs to have
    the same width/height as the current frame.
    If the re-assignment of prev_frame (just before the calls to
    frame_can_use_prev_frame_mvs()) were removed in some way, we could
    probably combine the two functions and often save a bit per frame
    The other slight tidy-up in the patch is to move re-allocation of the
    mvs buffer into onyxc_int.h: the code that did the allocation was
    duplicated between the encoder and decoder.
    [0] https://aomedia-review.googlesource.com/c/13806
    Change-Id: If25227fa24222fc05c56529c2ac9ddf1e1c36a84
onyxc_int.h 37.5 KB