Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.
Announcements
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.

UMC H.264 decoder

Purvin_Pandit
Beginner
213 Views
Hi
I have a H.264 bitstream (fields only) with intra refresh (no I/IDR only P fields) + recovery point SEI. The bitstream does not start at frame_num = 0. It starts at frame_num = 201, now after the frame_num wraps and the next time a frame with frame_num = 201 arrive the old frame_num = 201 is still in the Decoded list. Not sure why it is not removed.
This bitstream can be decoded by JM and other decoders. Is there a known issue when a bitstream does not begin with frame_num = 0, has recovery point SEI?
Thanks,
-Purvin
0 Kudos
3 Replies
Purvin_Pandit
Beginner
213 Views
Digging a little more I found this code in:
bool TaskSupplier::AddSlice(H264MemoryPiece * pMem, MediaData * pSource)
if (NumShortTermRefs + NumLongTermRefs == 0)
{
....
.....
if (sliceHeader->field_pic_flag)
{
pFrame->setPicOrderCnt(m_PicOrderCnt,0);
pFrame->setPicOrderCnt(m_PicOrderCnt,1);
}
else
{
pFrame->setPicOrderCnt(m_TopFieldPOC, 0);
pFrame->setPicOrderCnt(m_BottomFieldPOC, 1);
}
}

Looks like this is done only for the 1st field (in my case) so it sets the top & bottom POC to be the same. This is causing the problem where the bottom field is never removed. This looks like a bug. Can someone confirm?
Chao_Y_Intel
Employee
213 Views


Purvin,

Would it be possible to attach the test stream? Our expert comments that this is not very clear on what is happeing from the description.

Thanks,
Chao

Purvin_Pandit
Beginner
213 Views
Thanks Chao. I will try to get a bitstream to you as soon as I can.
-Purvin
Reply