)]}'
{
  "commit": "891f2dc25a1d779cd22e99544e09069f66173fdc",
  "tree": "506fb9a2610c183249584c4673c577188b7af645",
  "parents": [
    "f277ca3b49d1697231b8a4bf5d87c4f9faa388e3"
  ],
  "author": {
    "name": "Cheng Chen",
    "email": "chengchen@google.com",
    "time": "Mon Feb 26 14:55:58 2018 -0800"
  },
  "committer": {
    "name": "Cheng Chen",
    "email": "chengchen@google.com",
    "time": "Tue Feb 27 18:01:28 2018 +0000"
  },
  "message": "Wrap around current_video_frame and frame_offset\n\nWe removed resetting of current_video_frame when a keyframe is\ninserted at decoder. And current_video_frame continues to\naccumulate, which will overflow eventually, leading to mismatches\nbecause of incorrect frame distance computation.\n\nIt may not be a big issue for encoder, since we still reset\ncurrent_video_frame to 0 when a keyframe is inserted.\nAnd in a typical coding setting, we insert keyframe every\n150 frames. So current_video_frame will not overflow.\n\nHence, we wrap the current_video_frame and frame_offset to a small\nrandom value at decoder, when they reach a predefined limit\nFRAME_NUM_LIMIT \u003d INT_MAX - MAX_FRAME_OFFSET - 1.\n\nIn reality, it is unlikely to code so many frames and thus unable\nto test. I therefore set FRAME_NUM_LIMIT \u003d 20 and testes the coding\nresult locally with speed 2. It is the same as baseline.\n\nChange-Id: I42928a5154319f0faf87251cd57c0094c605cf41\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "d48d0fd9c58495ca18bafedb15fbdaf2ff765f8c",
      "old_mode": 33188,
      "old_path": "av1/common/enums.h",
      "new_id": "6d95a84207d995cffdba0be6db57f62a77edc7e0",
      "new_mode": 33188,
      "new_path": "av1/common/enums.h"
    },
    {
      "type": "modify",
      "old_id": "c0dad11aaa7e6bfb4e437d5a97ca26560e5b1e75",
      "old_mode": 33188,
      "old_path": "av1/decoder/decodeframe.c",
      "new_id": "a3a5a886ac196db6453bcbe6edb38b24f00e25a9",
      "new_mode": 33188,
      "new_path": "av1/decoder/decodeframe.c"
    }
  ]
}