View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000296 | JVT JM H.264/AVC reference software | encoder | public | 2012-03-26 17:07 | 2012-04-11 18:28 |
| Reporter | Pierre Andrivon | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | RedHat | OS | Linux x64 | ||
| Product Version | JM 18.3 | ||||
| Summary | 0000296: Crash 14 bits encoding | ||||
| Description | Crash with HM-like (RA) config files in Release mode gcc 4.1.2 (x64) - 14 bits - QP 37 encoding. No crash with other tested QP... (init' issue ?) No crash with same platform and Debug mode. No crash reported on win32/x64. Content used: SVT Parkjoy 14 bits 1920x1080 rescaled with provided Lanczos 3 filter from avisynth. Attached: config file used + Valgrind report. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
Actually this bug appeared on win32/x64 platform too (14 bits content as a source)... It seems that it comes from the fact that sometimes in function : int mode_decision_for_I16x16_MB_RDO (rd_intra_jm.c) l. 516 if(rdcost < min_rd_cost) l. 518 is never fulfilled for the whole loop (k=1..4) so that the "memcpy" of "BestCofAC/DC" never happens. In consequences, as these structures are not initialized, bad data (actually, uninitialized data) makes cabac crash later. I am working on it asap... |
|
|
I don't think whoever wrote this ever tested the function when in 14 bits. The code seems weird since the first memcpy should probably be of size sizeof(int) * 65. That is: memcpy(bestCofAC[b8][b4][0], currSlice->cofAC[b8][b4][0], sizeof(int) * 65); I guess setting bestCofAC and bestCofDC to zero also wouldn't hurt. I would though suggest increasing DISTBLK_MAX. In your case you have (2^14 - 1)^2 * 2^8 max possible distortion which is approximately equal to 2^36. That could result in issues with the current set value. I would think that maybe changing the #define to: #define DISTBLK_MAX ((distblk) INT_MAX << (2 * LAMBDA_ACCURACY_BITS)) Maybe safer and may make the code more futureproof, i.e. for supporting 16 bit inputs also. Probably multiplying by 4 would also be okay. I have of course not tested this. You can also try disabling I16RDOpt btw. Best regards, Alexis |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-03-26 17:07 | Pierre Andrivon | New Issue | |
| 2012-03-26 17:07 | Pierre Andrivon | File Added: crash_JM183_14bits.zip | |
| 2012-04-11 10:07 | Pierre Andrivon | Note Added: 0000526 | |
| 2012-04-11 18:28 | Alexis Michael Tourapis | Note Added: 0000528 | |
| 2012-04-11 18:49 | Alexis Michael Tourapis | Note Edited: 0000528 |
