View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000292 | JVT JM H.264/AVC reference software | encoder | public | 2012-02-23 03:33 | 2012-11-12 16:38 |
| Reporter | amanda | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| OS | Win7 | ||||
| Product Version | JM 18.3 | ||||
| Summary | 0000292: High 444 and field mode for CABAC | ||||
| Description | #define ENABLE_FIELD_CTX 1 #define ENABLE_HIGH444_CTX 1 And for 4:4:4, INIT_FLD_MAP_I[], INIT_FLD_MAP_P[] and etc. are not define the value for chroma cabac block type from CB_16DC to CR_4x4. Is it ok? It may be error when YUV444 and field mode. | ||||
| Tags | No tags attached. | ||||
|
|
4:4:4 interlace is a very weird format and it is my impression not really used by anyone. Maybe that is why the authors did not define it in the code. |
|
|
A loop at ldecod/src/context_ini.c:90 iterates i from 0 to 21 while the table INIT_FLD_MAP_I and INIT_FLD_MAP_P are defined only up to 7 On windows, when the iteration goes out of bounds, values from a following table are read. On linux however the out of bounds data is different. I haven't found where are is the data taken from and I do not think there is a point in finding it out. A funny thing is that on windows both encoder and decoder have the same bug and therefore they cooperate nicely. The proposed solution is to find out what should be the out of bound data and extend the tables correctly. BTW: We are trying to support 444 interlace, so there is at least one party using it ;) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-02-23 03:33 | amanda | New Issue | |
| 2012-02-23 03:51 | Alexis Michael Tourapis | Note Added: 0000517 | |
| 2012-11-12 16:38 | Dominik Wójt | Note Added: 0000559 |
