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

[Michael Niedermayer]

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


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090618/0ca3c6cf/attachment.pgp>