Intel® Integrated Performance Primitives
Community support and discussions relating to developing high-performance vision, signal, security, and storage applications.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
For the latest information on Intel’s response to the Log4j/Log4Shell vulnerability, please see Intel-SA-00646

Bug in H.264 encoder

Emmanuel_W_
New Contributor I
153 Views

It seems there is a bug while encoding chroma components in the H.264 encoder.

The function H264CoreEncoder_EncodeChroma encode in one shot both the U and V components. It starts with the U and upon reaching the first block of the V components switch pointers to the V plane. However, the condition to switch components doesn't seem right and upon reaching block 2 of the V components the U pointer are used again.

Emmanuel

0 Kudos
1 Solution
Leonid_K_Intel
Employee
153 Views

Emmanuel, the "do" loop has only 2 iterations, so that uBlock is first U (==16) at first and then firstV (==16+num_blocks[chroma]) at second time. There are few different block loops inside do{}, like

for (uBlock = startBlock; uBlock < uLastBlock; uBlock ++)

Regards,
Leonid

View solution in original post

5 Replies
Vladimir_Dudnik
Employee
153 Views
Hello Emmanuel,

thanks for reporting on this. Could you please specify what version of IPP do you use? Just worrying if you had a chance to try the latest IPP 6.1 update 1 version?

Regards,
Vladimir
Emmanuel_W_
New Contributor I
153 Views
Hello Emmanuel,

thanks for reporting on this. Could you please specify what version of IPP do you use? Just worrying if you had a chance to try the latest IPP 6.1 update 1 version?

Regards,
Vladimir

Hi Vladimir,

I have IPP 6.1 update 1 and latest sample version.

Emmanuel
Vladimir_Dudnik
Employee
153 Views
Thenks, I'll pass this information to development team.

Vladimir

Leonid_K_Intel
Employee
154 Views

Emmanuel, the "do" loop has only 2 iterations, so that uBlock is first U (==16) at first and then firstV (==16+num_blocks[chroma]) at second time. There are few different block loops inside do{}, like

for (uBlock = startBlock; uBlock < uLastBlock; uBlock ++)

Regards,
Leonid

View solution in original post

Emmanuel_W_
New Contributor I
153 Views
Thenks, I'll pass this information to development team.

Vladimir


Sorry for the fast alarm. I have modified this part of the code on my side and though I was looking at the original Intel code.

Emmanuel
Reply