I happened to find that there is no flicker when playbin2 is used.
then I found there is 'queue' between vaapidecode and vaapisink,
next I found there is no flicker in following command line:
gst-launch-0.10 -v filesrc
location=/root/video/H264_Main@L4.1_1920x1080_10.1Mbps_30.0fps_Interlaced_Sound_Surf.mpg
! mpegtsdemux ! vaapidecode ! queue ! vaapisink

so, I guess, a frame is sent to render when its second filed isn't ready.

Created attachment 245712 [details] [review]
fix the bug

We shouldn't output an interlaced frame when the first field comes even if it is a non-ref picture, it will lead to flicker.
we can safely add this non-ref frame to dpb and handle it when dpb_add is called next time.
in this way, we need increase dpb array size by one.

Hi, could you please upload the file to tinderbox? Thanks.

So far, the DPB was correctly generated for all H.264 streams I had (including interlaced) vs. the JM reference decoder. So, I will have to investigate further. The DPB should include the first field too, but it is not output yet. So, there is no need to grow the DPB size.

agree that DPB is correct;
but we shouldn't output a frame just after its first field is decoded.

two fields of a frame shares the same surface in GEN/PVR driver, so we'd wait the complete of the second filed to output a frame.

then add all non-ref pictures (even if it has the smallest poc) is the quick and easy way to fix such situation.

It is technically allowed to output the first field, without waiting for the second field. However, in Wayland context, we never handled the top|bottom field flags. I had some changes to protocol/mesa but that was not merged yet. Alternative is to use VPP, but this brings overhead.

BTW, I did not find the clip, where is it? Does this happen on X11 too? Thanks.

the bug is reported on X11, not wayland.
here is the content:
http://halley-sandy.sh.intel.com/share/h264-1080-interlaced.mpg

Hi, the current approach was to retain the field until we have a complete frame to output. However, this is wrong for two reasons: (i) you can have situations where you never receive the complement field, i.e. there is none or it was lost; and (ii) retaining the field longer than expected incurs additional latency, i.e. you need to parse and decode one more field, which means further waiting for the start code prefix following that one.

Besides, this specific bitstream contains SEI messages (PicTiming) that need to be supported. Those are hints that an emitted field needs to be displayed as a single field for example, thus not requiring vaapipostproc in-between.

Last but not least, I have tested the clip against JM and vaapidecode: the DPB states and output times are identical. So, I am not going to change gst-vaapi behaviour. Rather, the next steps are actually to support SEI messages (PicTiming) correctly and refinements to the deinterlacing process.

some agree and disgrees
> (i) you can have situations where you never receive the complement field, i.e. there is none or it was lost; 
it isn't matter, one (incomplete) frame still gets rendered when next frame comes by dpb_bump();
> (ii) retaining the field longer than expected incurs additional
latency,
it's better than render one frame before the 2nd field is ready, current frame is rendered once upon first field (does nothing upon second field).
> Rather, the next steps are actually to support SEI messages (PicTiming) correctly and refinements to the deinterlacing process.
agree.
in order to display a frame once (whole frame) or twice (each for one field), h264 dpb requires rewrite.

(In reply to comment #9)
> > (ii) retaining the field longer than expected incurs additional
> latency,
> it's better than render one frame before the 2nd field is ready, current frame
> is rendered once upon first field (does nothing upon second field).

This is a valid behaviour. For this particular clip, correct handling of SEI messages is missing.

> > Rather, the next steps are actually to support SEI messages (PicTiming) correctly and refinements to the deinterlacing process.
> agree.
> in order to display a frame once (whole frame) or twice (each for one field),
> h264 dpb requires rewrite.

You don't need a rewrite of the H.264 DPB, it's fine as is. You just need to support SEI messages and tag the picture accordingly.

Changes to the DPB cannot be accepted, this implementation is strictly conforming to the specs. Another solution is to introduce the concept of delayed_picture to wait for the next field. If next picture to be output is a frame, or a field with same parity, then emit the previous delayed picture. I will work on that.

The SEI messages are a hint that could be handled later.

commit f48b1e0cd6eb42d9260bb50318b44cdc2fbb8629
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Mon Jun 30 16:09:17 2014 +0200

    decoder: h264: fix output of second field when first field is not in DPB.
    
    Fix decoding of interlaced streams where a first field (e.g. B-slice)
    was immediately output and the current decoded field is to be paired
    with that former frame, which is no longer in DPB.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=701340