View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000040 | JVT JM H.264/AVC reference software | encoder | public | 2007-04-03 11:15 | 2011-05-19 12:32 |
| Reporter | Karsten Suehring | Assigned To | Alexis Michael Tourapis | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | any | ||||
| Product Version | JM 12.2 | ||||
| Fixed in Version | JM 16.1 | ||||
| Summary | 0000040: RC bug when recoding MBs | ||||
| Description | Reported by Christian Schmidt: I believe I have found a small bug in the JM 12.2 encoder. The function "void write_one_macroblock (int eos_bit)" always increases the number of coded MBs: /*record the total number of MBs*/ img->NumberofCodedMacroBlocks++; However, if the MB just written needs to be recoded for some reason (e.g. due to max slice size restriction when encoding with SliceMode=2 SliceArgument=512), the value img->NumberofCodedMacroBlocks is not corrected (decreased) accordingly. Subsequently, this number diverges from the real # of coded MBs and throws of the rate control... Original source & proposed fix (inline): slice.c :: encode_one_slice .... if (recode_macroblock == FALSE) { ... } else { //!Go back to the previous MB to recode it img->current_mb_nr = FmoGetPreviousMBNr(img->current_mb_nr); // Christian Schmidt, 3/28/2007: Proposed fix? img->NumberofCodedMacroBlocks--; // CS, 3/28/2007 ... } Could someone verify that this is the correct fix (and does not break anything else)? As a follow-up to that: It seems it is also necessary to backup the rate control data (quadratic_rc and generic_rd), so that it too can be restored in that case. In slice.c :: encode_one_slice, I see sth along those lines for the MBAFF encoding path, but not for the NON-MBAFF path. Christian | ||||
| Additional Information | Athanasios Leontaris confirmed this: You are right in both of your observations: (a) img->NumberofCodedMacroBlocks has to be decremented, and (b) the rate control state information (generic_rc and quadratic_rc structures/objects) has to be saved and restored to ensure correct rate control operation for SliceMode=2 and MB recoding. The rate control prior to JM 12.0 supported neither RDPictureDecision nor PicAFF or MBAFF coding, and MB recoding was broken as well. We reorganized it so that the state could be saved and restored in part to enable correct rate control for cases such as the above. Due to priorities and time constraints we did not modify the rate control for SliceMode=2 recoding, but as you have remarked it should be straightforward to do due to the flexibility of the new source code structure. Apart from MB recoding, the RC can easily be modified to allow picture recoding, such as in PicAFF. Even though not currently supported, one could reuse statistics gathered at the first run to improve the second run as well. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-04-03 11:15 | Karsten Suehring | New Issue | |
| 2007-04-03 11:16 | Karsten Suehring | Status | new => confirmed |
| 2011-05-19 12:32 | Karsten Suehring | Note Added: 0000479 | |
| 2011-05-19 12:32 | Karsten Suehring | Status | confirmed => resolved |
| 2011-05-19 12:32 | Karsten Suehring | Fixed in Version | => JM 16.1 |
| 2011-05-19 12:32 | Karsten Suehring | Resolution | open => fixed |
| 2011-05-19 12:32 | Karsten Suehring | Assigned To | => Alexis Michael Tourapis |
