H264POC: Allow gaps in frame_num.

media/video/h264_poc.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include <stddef.h>
 
 #include <algorithm>
 
 #include "base/logging.h"
 #include "base/macros.h"
@@ skipping 44 matching lines @@
 
 bool H264POC::ComputePicOrderCnt(
     const H264SPS* sps,
     const H264SliceHeader& slice_hdr,
     int32_t *pic_order_cnt) {
   if (slice_hdr.field_pic_flag) {
     DLOG(ERROR) << "Interlaced frames are not supported";
     return false;
   }
 
-  // TODO(sandersd): Handle |gaps_in_frame_num_value|.
-  if (prev_frame_num_ > 0 && prev_frame_num_ < slice_hdr.frame_num - 1) {
-    DLOG(ERROR) << "Gaps in frame_num are not supported";
-    return false;
-  }
-
   bool mmco5 = HasMMCO5(slice_hdr);
   int32_t max_frame_num = 1 << (sps->log2_max_frame_num_minus4 + 4);
   int32_t max_pic_order_cnt_lsb =
       1 << (sps->log2_max_pic_order_cnt_lsb_minus4 + 4);
 
+  if (!slice_hdr.idr_pic_flag &&
+      slice_hdr.frame_num != (prev_frame_num_ + 1) % max_frame_num) {

[Pawel Osciak, 2016/05/20 00:21:31]

Not sure if this is intentional, but this changes the logic so that frame_num
has to be strictly larger than prev_frame_num, although them being equal is
sometimes valid (even without gaps).

[sandersd (OOO until July 31), 2016/05/20 00:39:09]

My understanding of the spec is that this only happens when there is interlacing
(not implemented by H264POC yet) or redundant pictures (these are not passed to
H264POC).

Would you prefer that H264POC can handle (or internally ignore) redundant
pictures?

[Pawel Osciak, 2016/05/20 07:50:12]

I just thought that not changing the condition would keep the existing behavior,
but please feel free to make a decision based on what is supported by VTVDA.

+    // We don't do any special handling of gaps in |frame_num|, because the
+    // computations below are unaffected by them. In particular, wrapping is
+    // handled the same whether we simulate the missing frames or not.
+    if (!sps->gaps_in_frame_num_value_allowed_flag)
+      DLOG(WARNING) << "Invalid gap in frame_num.";
+  }
+
   // Based on T-REC-H.264 8.2.1, "Decoding process for picture order
   // count", available from http://www.itu.int/rec/T-REC-H.264.
   //
   // Reorganized slightly from spec pseudocode to handle MMCO5 when storing
   // state instead of when loading it.
   switch (sps->pic_order_cnt_type) {
     case 0: {
       int32_t prev_pic_order_cnt_msb = ref_pic_order_cnt_msb_;
       int32_t prev_pic_order_cnt_lsb = ref_pic_order_cnt_lsb_;
 
@@ skipping 133 matching lines @@
 
     default:
       DLOG(ERROR) << "Invalid pic_order_cnt_type: " << sps->pic_order_cnt_type;
       return false;
   }
 
   return true;
 }
 
 }  // namespace media