search

OpenVisualCloud / SVT-HEVC

SVT HEVC encoder. Scalable Video Technology (SVT) is a software-based video coding technology that is highly optimized for Intel® Xeon® processors. Using the open source SVT-HEVC encoder, it is possible to spread video encoding processing across multiple Intel® Xeon® processors to achieve a real advantage of processing efficiency.
Other
519 stars 169 forks source link

Fixed the SegFault issue for 64x64 fractional search in ME. #482

Closed Austin-Hu closed 4 years ago

Austin-Hu commented 4 years ago

The issue happens when 64x64 fractional search is enabled with encMode 0~2. Occationally the calculated xSearchIndex in PU_HalfPelRefinement() could be less than 0. So getting the Y pixels of reference buffer (integerBufferPtr of ME context) can be done by forward shift, rather than indexing. Because integerBufferPtr locates at some middle region region of the PA reference buffer's Y component, and it's "legal" to access its preceding memory region.

Signed-off-by: Austin Hu austin.hu@intel.com

Fixes #481 .

Austin-Hu commented 4 years ago

I'm using the latest commit of master branch plus PR #482 , with the same command line you reported, but I didn't see crashing here with several times running:

./SvtHevcEncApp -i SlideShow_1280x720.yuv -w 1280 -h 720 -asm 0 -encMode 0 -intra-period 100 -scd 0 -rc 0 -q 22 -n 100 -b 0.265

BTW, as I mentioned in the commit comments, (ySearchIndex * (EB_S32)refStride + xSearchIndex) could be negative number, but refBuffer points to some middle range of the refPicPtr->bufferY buffer, so the data ahead of it can be accessed.

Austin-Hu commented 4 years ago

Temporarily worked around this issue by resetting best MV for each LCU, and will continue tracing its root cause. BTW, the bitstreams are exactly the same after encoding other YUV inputs.

Austin-Hu commented 4 years ago

Presuming encoding speed was the same with the fix as well as the bitstream being identical?

Yes. But right now the change hasn't been confirmed as a fix, and it's not the right time to compare encoding performance.

tianjunwork commented 4 years ago

My fix is #define MAX_SAD_VALUE 64*64*255 ==> #define MAX_SAD_VALUE 64*64*255+1, similar to Mark's fix. With this change, FullPelSearch_LCU guarantees to update the mv. 64 is the max lcu size, 255 is the max SAD of a pixel.

PDX-Runner commented 4 years ago

has Hassene confirmed that this is the right fix or it is still a temporal work around? if we know how much padding area is allocated for the reference frame buffer, can we simply clamp the ME search area to be inside the reference frame buffer + padding area?

tianjunwork commented 4 years ago

Hi @PDX-Runner , currently there are two proposal to fix: 1. init the mv before doing full pixel search(otherwise, mv is same as the previous one), 2. adjust SAD value to make sure mv is updated for sure during full pixel search. Both of them are not confirmed by Hassene. We will look into it today still to find the root cause.