View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000216 | JVT JM H.264/AVC reference software | decoder | public | 2010-06-30 23:46 | 2012-04-10 18:28 |
| Reporter | Dzung Hoang | Assigned To | Karsten Suehring | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | JM 17.1 | ||||
| Fixed in Version | JM 18.0 | ||||
| Summary | 0000216: wrong PSNR is computed for pictures after second IDR in a bitstream | ||||
| Description | The PSNR computation when given a reference YUV file is incorrect starting from the second IDR picture. | ||||
| Additional Information | Here is a proposed fix. Replace the following line in calculate_frame_no() in image.c: p_Vid->idr_psnr_number = p_Vid->number*p_Vid->ref_poc_gap/(p_Inp->poc_scale); with p_Vid->idr_psnr_number = p_Vid->g_nFrame*p_Vid->ref_poc_gap/(p_Inp->poc_scale); | ||||
| Tags | No tags attached. | ||||
| has duplicate | 0000297 | new | Bad PSNR stats at the decoder side |
|
|
The code unfortunately requires some restructuring to properly compute PSNR values for all cases. The right solution would be to computer PSNRs when and only when the image is writen to a file since at that point all dependencies in terms of frame position are known (i.e. there could be frames that precede the IDR in time but follow it in terms of encoding. Your suggested solution only handles cases where such frames do not exist. We are aware of this bug but other issues were of higher importance and that is why we have not fixed this. |
|
|
I have verified my proposed fix. Since it is a one-liner, it should be a no-brainer to put in. |
|
|
There is actually no way of properly calculating PSNR at the decoder. It will always be based on guessing the structure of the reference. But I think if the patch improves some guesses and does not have influence on other situations, we should add it. |
|
|
No one said that your fix cannot work for some cases or that we will not add this (actually that was the reason why the Vid->g_nFrame was there but I don't know why it was not considered). I actually did update my working system with this. As said though, it works for cases where there are no pictures with negative POCs that may affect the sequence reconstruction process. The right way it to restructure the code based on the output picture process which would help the "guessing" process even more. |
|
|
Am more sophisticated guessing algorithm has been added to calculate_frame_no() |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-06-30 23:46 | Dzung Hoang | New Issue | |
| 2010-07-09 07:46 | Alexis Michael Tourapis | Note Added: 0000379 | |
| 2010-07-09 19:39 | Dzung Hoang | Note Added: 0000381 | |
| 2010-07-09 20:18 | Karsten Suehring | Note Added: 0000382 | |
| 2010-07-09 23:07 | Alexis Michael Tourapis | Note Added: 0000383 | |
| 2011-04-05 18:18 | Karsten Suehring | Note Added: 0000424 | |
| 2011-04-05 18:18 | Karsten Suehring | Status | new => resolved |
| 2011-04-05 18:18 | Karsten Suehring | Fixed in Version | => JM 18.0 |
| 2011-04-05 18:18 | Karsten Suehring | Resolution | open => fixed |
| 2011-04-05 18:18 | Karsten Suehring | Assigned To | => Karsten Suehring |
| 2012-04-10 18:28 | Alexis Michael Tourapis | Relationship added | has duplicate 0000297 |
