MJPEGVideoDecoder Buffer Overrun

[Steve_Browne]

I recently ran into a buffer overrun problem when using the MJPEGVideoDecoder in the sample code. I've tracked it down and came up with a valid workaround without modifying the sample code, but a fix to the sample code would be nice.

I'm using IPP Version 6.1.1 with the sample code version 6.1.1.044 on Windows. Although I have seen this problem since Version 5.2. I upgraded to 6.1.1 hoping to fix it before I started digging deeper into the issue.

Basically it appears thatCJPEGDecoder only allocates m_block_buffer in Init() which will only happen for the first frame of MJPEGVideoDecoder. The problem is that this buffer size is based upon some information in the JPEG header which is not necessarily the same for all of the JPEGs. For example after parsing the SOF0 from the first JPEG it determines that m_nblock is 3. Well a few frames later one of the JPEGs has a SOF0 that after parsing results in m_nblock being 6, but the buffer does not get reallocated toaccommodatethe larger size needed. The end result is a buffer overrun or access violation in CJPEGDecoder::DecodeScanBaselineIN() because it assumes the buffer is stillm_numxMCU * m_nblock * DCTSIZE2 which it isn't because m_nblock has increased.

My work around if anyone is interested is to call Reset() on the MJPEGVideoDecoder before every GetFrame() call. This will in turn force it to treat it as if it is the first frame and allocate the buffer accordingly.

[Emmanuel_W_]

Quoting - amn3sia

I recently ran into a buffer overrun problem when using the MJPEGVideoDecoder in the sample code. I've tracked it down and came up with a valid workaround without modifying the sample code, but a fix to the sample code would be nice.

I'm using IPP Version 6.1.1 with the sample code version 6.1.1.044 on Windows. Although I have seen this problem since Version 5.2. I upgraded to 6.1.1 hoping to fix it before I started digging deeper into the issue.

Basically it appears thatCJPEGDecoder only allocates m_block_buffer in Init() which will only happen for the first frame of MJPEGVideoDecoder. The problem is that this buffer size is based upon some information in the JPEG header which is not necessarily the same for all of the JPEGs. For example after parsing the SOF0 from the first JPEG it determines that m_nblock is 3. Well a few frames later one of the JPEGs has a SOF0 that after parsing results in m_nblock being 6, but the buffer does not get reallocated toaccommodatethe larger size needed. The end result is a buffer overrun or access violation in CJPEGDecoder::DecodeScanBaselineIN() because it assumes the buffer is stillm_numxMCU * m_nblock * DCTSIZE2 which it isn't because m_nblock has increased.

My work around if anyone is interested is to call Reset() on the MJPEGVideoDecoder before every GetFrame() call. This will in turn force it to treat it as if it is the first frame and allocate the buffer accordingly.

Thanks for the info

Emmanuel

[Steve_Browne]

I just wanted to follow up on this in case anyone else found this useful. I found that calling Reset() on the MJPEGDecoder every frame results in a memory leak. Instead I have to re-init the decoder before every GetFrame() call in order to prevent the memory leak and not get buffer overrun issues.