Problems with JVT-D018r0

1
Problems with JVT-D018r0

• As presented, remapping of picture numbers will
  not work because this is supposed to be based on
  picture numbers rather than index positions for
  error resilience reasons
• Burdens people who do only frame-structured
  coding (e.g., people coding progressive-scan
  content) with the need to try to think in strange
  interlace-oriented terms
• Picture number values and MMCO commands are
  inefficient for frame-structured coding
  (burdening people not only with strange
  interlace-oriented thinking, but with strange
  interlace-oriented bits)

2
Alternative DesignField-Structured Picture
Numbering

• Each field has a frame_number and an indication
  of whether it is the top or bottom field of the
  frame (not first or second, but rather only top
  or bottom)
• There shall be at most one top field and at most
  one bottom field for each frame_number.
• If both fields of the frame are present in the
  bitstream, they shall be adjacent to each other
  in transmission order
• frame_number is incremented by one relative to
  value in the last stored field of a different
  frame. The change of frame_number is the
  indication of whether it is a different frame.
• If only one field of a frame is in the buffer,
  there is no space reserved in the multi-frame
  buffer for the other field that isnt there.

3
xxx ---- Alternative Designxxxx ----
Field-Structured Picture Indexing

• Indexing and indexing order are field-based
• In a remapping of frame numbers operation, after
  each abs_diff_frame_numbers or long_term_frame_ind
  ex is sent a two-bit field_remap_indicator.
• field_remap_indicator has four possible values
• 00 Remap the index order of the top field
• 01 Remap the index order of the bottom field
• 10 Remap the index order of both fields with
  the top one being first in the new index order
• 11 Remap the index order of both fields with
  the bottom one being first in the new index order

4
Alternative Design Field-Structured Picture
Indexing

• Indexing and indexing order are field-based
• In a remapping of frame numbers operation,
  instead of abs_diff_frame_numbers or
  long_term_frame_index, send abs_diff_field_numbers
  or long_term_field_index, where the field number
  is derived by doubling the frame number and
  adding 1 if addressing the opposite field.

5
xxxxAlternative DesignxxxxField-Structured
Picture MMCO

• In an MMCO command, after each difference_of_frame
  _numbers or long_term_frame_index, there are two
  bits that follow mmco_top_flag and
  mmco_bottom_flag. These flags indicate which
  fields are marked unused by the MMCO command.
  At least one of these two flags shall be 1.

6
Alternative DesignField-Structured Picture MMCO

• In an MMCO command, instead of sending
  difference_of_frame_numbers or long_term_frame_ind
  ex, send difference_of_field_numbers or
  long_term_field_index, derived in similar fashion
  as for indexing.

7
Alternative DesignFrame-Structured Picture
Frame Numbering

• frame_number increments by one relative to the
  value of frame_number in the last stored field or
  frame
• Dangling fields in the multi-picture buffer are
  not included in the indexing order and cannot be
  remapped

8
Alternative DesignFrame-Structured Picture
Indexing

• Only complete frames can be indexed in either the
  default or non-default indexing order for each
  picture (dangling fields are not included in any
  indexing order)
• abs_diff_frame_numbers or long_term_frame_index
  is used, which applies to entire frame

9
Alternative DesignFrame-Structured Picture MMCO

• In an MMCO command, send a difference_of_frame_num
  bers
• The MMCO command applies to all fields of the
  indicated frame_number that are in the
  multi-picture buffer.
• If in sliding window mode, and one dangling field
  is at the end, that field and the field of
  opposite parity relative to the parity of that
  field, are marked unused.
• Comment Allow field-based MMCO commands when the
  current picture is a frame-structured picture?