View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000227JVT JM H.264/AVC reference softwareencoder and decoderpublic2010-07-29 16:232011-03-30 20:10
Reporterllzzyynjupt Assigned ToKarsten Suehring  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product VersionJM 17.2 
Fixed in VersionJM 18.0 
Summary0000227: two possible bugs of JM 17.2
DescriptionProblem 1.

Encoder Side:
In the function “update_pic_num()” of the file “mbuffer.c”, there are codes like this:
Code Fragment Start:
          if( p_Dpb->fs_ref[i]->frame_num > currSlice->frame_num )
          {
#if (MVC_EXTENSION_ENABLE)
            if ( p_Inp->num_of_views == 2 )
              p_Dpb->fs_ref[i]->frame_num_wrap = p_Dpb->fs_ref[i]->frame_num - (currSlice->max_frame_num << 1);
            else
#endif
            p_Dpb->fs_ref[i]->frame_num_wrap = p_Dpb->fs_ref[i]->frame_num - currSlice->max_frame_num;
          }
          else
          {
            p_Dpb->fs_ref[i]->frame_num_wrap = p_Dpb->fs_ref[i]->frame_num;
          }
          p_Dpb->fs_ref[i]->frame->pic_num = p_Dpb->fs_ref[i]->frame_num_wrap;
Code Fragment End.
So we can see that “p_Dpb->fs_ref[i]->frame->pic_num” may have a negative value.
In the function “poc_based_ref_management_frame_pic()” of the file “mmco.c”, there are codes like this:
Code Fragment Start:
  VideoParameters *p_Vid = p_Dpb->p_Vid;
  unsigned i, pic_num = 0;

  int min_poc=INT_MAX;
  DecRefPicMarking_t *tmp_drpm,*tmp_drpm2;

  if (p_Vid->dec_ref_pic_marking_buffer!=NULL)
    return;

  if ( p_Vid->currentPicture->idr_flag )
    return;

  if ((p_Dpb->ref_frames_in_buffer + p_Dpb->ltref_frames_in_buffer)==0)
    return;

  for (i = 0; i < p_Dpb->used_size; i++)
  {
    if (p_Dpb->fs[i]->is_reference && (!(p_Dpb->fs[i]->is_long_term)) && p_Dpb->fs[i]->poc < min_poc)
    {
      min_poc = p_Dpb->fs[i]->frame->poc ;
      pic_num = p_Dpb->fs[i]->frame->pic_num;
    }
}
Code Fragment End.
So “p_Dpb->fs[i]->frame->pic_num” may give a negative value to the “unsigned int” variable “pic_num”. This can happen when encoding the 16th frame using the attached “encoder.cfg” configuration file.
Therefore, in the function “poc_based_ref_management_frame_pic()” of the file “mmco.c”, pic_num should be a variable of type “int”. The same problem also exists in the function “poc_based_ref_management_field_pic()”.


Problem 2.

Encoder Side:
In the function “poc_based_ref_management_frame_pic()” of the file “mmco.c”, there are codes like this:
Code Fragment Start:
  tmp_drpm2->memory_management_control_operation = 1;
#if MVC_EXTENSION_ENABLE
  if(p_Vid->active_sps->profile_idc < MULTIVIEW_HIGH)
    tmp_drpm2->difference_of_pic_nums_minus1 = current_pic_num - pic_num - 1;
  else
    tmp_drpm2->difference_of_pic_nums_minus1 = (current_pic_num - pic_num)/2 - 1;
#endif
  p_Vid->dec_ref_pic_marking_buffer = tmp_drpm2;
Code Fragment End.
In the function “mm_unmark_short_term_for_reference()” of the file “mbuffer.c”, there are codes like this:
Code Fragment Start:
#if MVC_EXTENSION_ENABLE
  if(p_Dpb->p_Vid->active_sps->profile_idc >=MULTIVIEW_HIGH)
    picNumX = get_pic_num_x(p, (difference_of_pic_nums_minus1+1)*2-1);
  else
#endif
   picNumX = get_pic_num_x(p, difference_of_pic_nums_minus1);
Code Fragment End.
Decoder Side:
In the function “mm_unmark_short_term_for_reference()” of the file “mbuffer.c”, there are codes like this:
Code Fragment Start:
picNumX = get_pic_num_x(p, difference_of_pic_nums_minus1);
Code Fragment End.
We know that “MULTIVIEW_HIGH” is “118”. So if we encode using some profile larger than “118”, such as the “High 4:4:4 Predictive Profile (FREXT_Hi444)”, which has the value “244”, and the “High 4:2:2 prfile (FREXT_Hi422)”, which has the value “122”, the encoder and decoder will perform mismatched MMCO operations. In fact, if we encode using the attached “encoder.cfg” configuration file, the decoder will report “duplicate frame_num in short-term reference picture buffer” when decoding the 16th frame and then exit.
So the above “if” judegment statements should be modified to take these cases into consideration.


TagsNo tags attached.

Activities

2010-07-29 16:23

 

encoder.cfg (48,375 bytes)

Karsten Suehring

2011-03-30 20:10

administrator   ~0000416

First part is fixed in JM-17.2-dev (according to suggestion). The code that the second part refers to seems to be already cleaned up.

Issue History

Date Modified Username Field Change
2010-07-29 16:23 llzzyynjupt New Issue
2010-07-29 16:23 llzzyynjupt File Added: encoder.cfg
2011-03-30 20:10 Karsten Suehring Note Added: 0000416
2011-03-30 20:10 Karsten Suehring Status new => resolved
2011-03-30 20:10 Karsten Suehring Fixed in Version => JM 18.0
2011-03-30 20:10 Karsten Suehring Resolution open => fixed
2011-03-30 20:10 Karsten Suehring Assigned To => Karsten Suehring