View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000260 | JVT JM H.264/AVC reference software | encoder and decoder | public | 2011-05-06 16:36 | 2011-05-10 16:09 |
| Reporter | Sergey Silkin | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Platform | all | OS | all | OS Version | all |
| Product Version | JM 18.0 | ||||
| Summary | 0000260: "Sliding window decoded reference picture marking process" implemented incorrectly | ||||
| Description | Spec 8.2.5.3 tells that frame with smallest value of FrameNumWrap is marked as "unused for reference". But sliding_window_memory_management(...) function doesn't take into account values of FrameNumWrap. It marks oldest reference frame in input order as "unused for reference". | ||||
| Tags | No tags attached. | ||||
|
|
I think both processes lead to the same result. |
|
|
I hope the following example explains the difference. Num reference frames = 15 Max frame_num = 16 Frames 0, 15 and 16 are long-term references. They use the same LT index value. Below is diagramm of filling of DPB in JM decoder ('frame' - absolute frame number in input order, 'dpb' - index of frame buffer, 'unref' - frame that is marked as 'unused for reference' with memory management commands or with sliding window process): frame frame_num dpb unref 0lt 0 0 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8 9 9 9 10 10 10 11 11 11 12 12 12 13 13 13 14 14 14 15lt 15 0 0 16lt 0 0 15 17 1 1 JM marks frame 1 as 'unused for reference' within sliding_window_memory_management(...) at inserting frame 17 to DPB. But frame 1 has FrameNumWrap value equal to 1, which is not minimum value among frames that are stored in DPB. Frame 2 has FrameNumWrap value equal to -14. According to the spec frame 2 should be marked as 'unused for reference'. |
|
|
The stream that you are describing violates equation 7-23 in the standard text (see the semantics of frame_num) All my tries to construct an "evil" frame_num situation resulted in a violation of that constraint. |
|
|
|
|
|
JM encoder allows to encode such stream because sliding_window_memory_management(..) is implemented there with the same issue - it doesn't assume FrameNumWrap value. test.zip contains such stream. It has been encoded with JM18.0. slice.c and mmco.c has been modified - i just added there marking of 0,15,16 frames as long-term references (changes are highlighted with '//@@' string). Trace frame_num in sliding_window_memory_management(..) at decoding. At storing frame 17 in DPB it unmarks frame with frame_num = 1. Its FrameNumWrap is equal to 1. But frame with frame_num = 2 has FrameNumWrap = -14, and it should be unmarked first according to the spec. |
|
|
I think the required fix would be to prevent the encoder from generating streams that are not conforming to the H.264/AVC spec. For the decoder the spec does not say anything about handling invalid streams. So we automatically enter the area of error handling. I think the best action would be to remove any picture that should not be in the DPB, e.g. in this case frame 1 (so the code behaves in a way that makes sense). But we should make sure that this is always the case and that the decoder reports the error condition. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-05-06 16:36 | Sergey Silkin | New Issue | |
| 2011-05-06 16:44 | Karsten Suehring | Note Added: 0000459 | |
| 2011-05-08 12:36 | Sergey Silkin | Note Added: 0000460 | |
| 2011-05-09 16:06 | Karsten Suehring | Note Added: 0000461 | |
| 2011-05-09 18:09 | Sergey Silkin | File Added: test.zip | |
| 2011-05-09 18:22 | Sergey Silkin | Note Added: 0000462 | |
| 2011-05-09 18:23 | Sergey Silkin | Note Edited: 0000462 | |
| 2011-05-10 16:04 | Karsten Suehring | Note Added: 0000465 | |
| 2011-05-10 16:09 | Karsten Suehring | Status | new => acknowledged |
