[FFmpeg-cvslog] r25840 - trunk/tests/ref/fate/h264-conformance-frext-frext_mmco4_sony_b

[Baptiste Coudurier]

On 11/28/10 5:43 PM, Michael Niedermayer wrote:
> On Sun, Nov 28, 2010 at 03:57:12PM -0800, Baptiste Coudurier wrote:
>> On 11/28/10 3:36 PM, Reimar D?ffinger wrote:
>>> On Sun, Nov 28, 2010 at 03:15:44PM -0800, Baptiste Coudurier wrote:
>>>> On 11/28/10 3:13 PM, Alexander Strange wrote:
>>>>>
>>>>> On Nov 28, 2010, at 6:09 PM, bcoudurier wrote:
>>>>>
>>>>>> Author: bcoudurier
>>>>>> Date: Mon Nov 29 00:09:30 2010
>>>>>> New Revision: 25840
>>>>>>
>>>>>> Log:
>>>>>> Update fate h264 test due to r25824, this file has 2 frames delay
>>>>>>
>>>>>> Modified:
>>>>>>   trunk/tests/ref/fate/h264-conformance-frext-frext_mmco4_sony_b
>>>>>>
>>>>>> Modified: trunk/tests/ref/fate/h264-conformance-frext-frext_mmco4_sony_b
>>>>>> ==============================================================================
>>>>>> --- trunk/tests/ref/fate/h264-conformance-frext-frext_mmco4_sony_b	Sun Nov 28 22:17:39 2010	(r25839)
>>>>>> +++ trunk/tests/ref/fate/h264-conformance-frext-frext_mmco4_sony_b	Mon Nov 29 00:09:30 2010	(r25840)
>>>>>> @@ -1,60 +1,59 @@
>>>>>> -0, 0, 152064, 0x24846654
>>>>> ...
>>>>>> +0, 0, 152064, 0xd33945be
>>>>>
>>>>> What was in the first frame before?
>>>>
>>>> poc 1 was not outputed, and decoder realized that there was 2 frames
>>>> delay between the 1 and the third.
>>>
>>> Huh? The question was: Before the change there was one additional frame
>>> at the start, that had different content from all others. What did
>>> it contain?
>>
>> Hummm, the first frame I guess, it seems it is now dropped because
>> ffmpeg is buggy with raw h264. The decoder now outputs all the frames
>> though.
> 
> if adding -vsync 0 to that single fate test fixes it then iam ok with that
> though ideally, i would like to know why exactly this become needed now

-vsync 0 will avoid dropping the first frame, but still the ref in fate
is wrong. Ouput must contain 60 frames not 59.

Why is it needed now: because now delay 2 therefore vdelta is -2 and
vsync drops one frame. do_video_out only tolerates 1 frame delay
(< -1.1)
compute_pkt_fields doesn't generate any timestamps for raw h264, so
guess_correct_pts return ist->pts which is -0.8 (correct first dts) but
sync_opts is 0, there 2 frames sync delay, only drops one though.
ist->pts stays at -0.8 because next_pts is never increased (code skips
this part because decoder did not output any frame), and packet has not
dts set.

Is that understandable ? :)

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org