- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Chao. I will try to get a bitstream to you as soon as I can.
-Purvin

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page