Gray dots on white area in h264 encoder

[gennadii_mog]

Hello everyone,

I tried to encode absolutely white area with h264 encoder. As a result I had a gray dots on white area.
If broadcasting note absolutely white area then ok.
Does anybody have the same issue? How I can fix this problem?

Thanks,
Gennadii

[Emmanuel_W_]

Quoting - gennadii.mog

Hello everyone,

I tried to encode absolutely white area with h264 encoder. As a result I had a gray dots on white area.
If broadcasting note absolutely white area then ok.
Does anybody have the same issue? How I can fix this problem?

Thanks,
Gennadii

Can you post a screen shot?

[gennadii_mog]

Quoting - eweber

Can you post a screen shot?

In attachment you can find the encoded video and h264 params file.

[Ying_H_Intel]

Quoting - gennadii.mog

In attachment you can find the encoded video and h264 params file.

Hi Gennadii,

Can you also provide the original YUV file?

We noticed there are some gray background andwhite gridframes (as below)in the stream,are theythe gray dots you mean?

Regards,
Ying

[Emmanuel_W_]

Quoting - eweber

Can you post a screen shot?

I have actually seen that bug in the past while encoding some powerpoint presentation.

If I am not mistaking, this happens when encoding intra16 block made of solid white with a QP reaching 0.

I have actually patch the encoder code to not allow QP of 0 for that reason and forgot about it.

Emmanuel

[gennadii_mog]

Quoting - Ying H (Intel)

Hi Gennadii,

Can you also provide the original YUV file?

We noticed there are some gray background andwhite gridframes (as below)in the stream,are theythe gray dots you mean?

Regards,
Ying

In archive you will find parameters file, example of input stream and encoder's application (win32 platform)

[Ying_H_Intel]

Dear Gennadii,

I was able to reproduce this issue using your application. But when I tried to encode sample file you provided with your h264.par file using encoder that was built with IPP 6.1 Update 3 problem disappeared. I used IPP 6.1.3.047 and IPP samples 6.1.3.052.They can be downloaded from the Intel Registration Center:

https://registrationcenter.intel.com/regcenter/register.aspx

Best regards,
Artem

[Emmanuel_W_]

Any chance we can get more details on the problem.

Is there a specific IPP function that has been fixed or is it a sample fix?

I did some diff between the different versions of the samples but can't find anything obvious.

Thanks,

Emmanuel

[choonpark]

Hi Eweber,

I'm suffering from the exactly same issue. Could you please let me know where I have to change codes in h.264 part of IPPcode samples to not allow QP of 0. I tried it with IPPsample codes 6.1.5.060, but I had a same result.

FYI, if I take CABAC mode(1) in 'h264.par' with the test of umc_video_enc_con command, the white dots with gray background disappeared. However, in case of CAVLC mode, it happens again. Do you know why?



I appreciate it so much.

Choon

[choonpark]

Hi,

I'm suffering from the exact same issue.

BTW, if I take CABAC mode(1) in 'h264.par' with the test of umc_video_enc_con command, the white dots with gray background disappeared. However, in case of CAVLC mode, it happens again. Do you know why?

I also tried with 7.0 beta code samples, but I've got a same result. I think that there is still a same issue in 7.0 code samples.

Choon

[choonpark]

Hi,

If you change the value of 'N of frames in between I fraems' in "h264.par" under 'profile_idc = 66(BASELISE PROFILE)' mode, 'umc_video_enc_con' does it well & right.. Is there anybody who knows why?

..

[Leonid_K_Intel]

Hi all,
There is a bug in the code. The reason is incorrect requantization when coeff is greater than maximum allowed level for CAVLC in baseleine profile.

To avoid it don't use combination of CAVLC and baseline profile.

To fix it go to

H264CoreEncoder_CEncAndRec16x16IntraMB function, in the beginning, under

if

(!transform_bypass) after if( core_enc->m_info.profile_idc == 66...){
declare
COEFSTYPE buf[16];
copy there pDCBuf (sizeof(buf)),
then inside do{ under if( CAVLC_overflow ){
copy back from buf to pDCBuf.
That's all.

As you can see the bug is that in case of requantization already quantized coeffs were used instead of originals. The additional buffer needs to be used to preventoriginal source valuesbecauseippiTransformQuantLumaDC_H264 works inplace.In umc_h264_ermb_tmpl.cpp.h -> line 1333

if( core_enc->m_info.profile_idc == 66 && !core_enc->m_info.entropy_coding_mode ){
bool CAVLC_overflow;
Ipp32s i;
*COEFFSTYPE buf[16];
* memcpy( buf,pDCBuf, 16*sizeof( COEFFSTYPE ));
do{
H264ENC_MAKE_NAME(ippiTransformQuantLumaDC_H264)(
pDCBuf,
pQBuf,
uMBQP,
&iNumCoeffs,
1,
enc_single_scan[is_cur_mb_field],
&iLastCoeff,
NULL);
CAVLC_overflow = false;
for(i=0; i<16; i++)
if( pDCBuf > MAX_CAVLC_LEVEL ){ CAVLC_overflow = true; break; }
if( CAVLC_overflow ){
* memcpy(pDCBuf, buf,16*sizeof( COEFFSTYPE ));
cur_mb.LocalMacroblockInfo->QP++;
uMBQP = cur_mb.lumaQP = getLumaQP(cur_mb.LocalMacroblockInfo->QP, core_enc->m_PicParamSet.bit_depth_luma);
}
}while(CAVLC_overflow);