[FFmpeg-devel] [BUG] h264 picture reordering fails

[Haruhiko Yamagata]

>On Sun, May 31, 2009 at 05:51:33PM +0900, Haruhiko Yamagata wrote:
>>> On Sat, May 30, 2009, Haruhiko Yamagata wrote:
>>>>> On Sat, May 30, 2009 at 07:34:32PM +0900, Haruhiko Yamagata wrote:
>>>>>> I found picture reordering fails in
>>>>>> http://x264.nl/h.264.samples/premiere-paff.ts
>>>>>>
>>>>>> Outputted pictures have POC {-4, -2, 4, 0, 2, 6}.
>>>>>> Are negative POCs allowed?
>>>>>>
>>>>>> If yes, zero as POC is valid as well.
>>>>>>
>>>>
>>>>> about POCs, IIRC the spec requires POC=0 to be true and only true for
>>>>> IDR pictures, but i might misremember (would have to check the spec)
>>>>> What i do know is that the POC or frame number == 0 rules in the spec
>>>>> are not followed by some encoders.
>>>>
>>>> Yes, I think POC=0 means IDR. In that case, negative values as POC are
>>>> not allowed.
>> On Sun, May 31, 2009, fenrir wrote:
>>> This point has been discusses on the JVT mailing list, it was said that
>>> negative POC are valids, they just mean that the picture has to be 
>>> displayed
>>> before the IDR.
>>
>> OK, I understand.
>> Then negative POC should typically be -2, while longer reference chains are 
>> theoretically possible.
>>
>> Obviously it is not the case with mine. The frame with POC 0 happens to be 
>> a B frame.
>
>what POC value does the reference impl give that frame?
>If a B frame ends at POC=0 that seems a bug in the encoder and we should find
>a way to handle that POC=0 non IDR case not chnage POC
>OTOH
>if the reference gives it a POC != 0 then our poc code is buggy

JM decoder gives POC=0 to the B frame. The log attached.

I extracted the bitstream from the GDR frame to the end.
If you need the .264 file I used to get the log, please let me know.

Best regards,
Haruhiko Yamagata
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: JM_log.txt
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090618/209b2d66/attachment.txt>