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

[Michael Niedermayer]

On Thu, Jun 18, 2009 at 09:46:27PM +0900, Haruhiko Yamagata wrote:
>> 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.

could you try to remove all poc==0 checks related to picture ordering and
just leave the IDR checks, maybe that would work? (also has to be tested
against a few other streams ...)


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- 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/eabe39f5/attachment.pgp>