Hi,

(In reply to comment #0)
> Created an attachment (id=248802) [details] [review]
> 0001-h264-support-process-for-gaps-in-frame_num
> 
> 0001 patch is going to process 'non-exist' pictures and slide the reference
> window.
> 
> Follow 8.2.5.2 when frame_num is not equeal to
> PreRefFrameNum and is not equal to
> (PreRefFrameNum+1)%MaxFrameNum, there would be
> "non-existing" picture "used for short-term reference".

What clip is this patch intended to fix? Thanks.

have send the clip link by mail.

This patch is incomplete. The spec mentions additional constraints in various footnotes, that are not respected here. This will produce incorrect results for other clips too.

Created attachment 299243 [details] [review]
decoder: h264: add initial support for loss of pictures

Here is another patch, but it is far from complete. In particular, this might not work with MVC.

commit 5abd2b90b6b67403cd12e88496abf28e6fb39dc9
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Thu Mar 12 22:57:22 2015 +0100

    decoder: h264: add initial support for loss of pictures.
    
    Implement decoding process for gaps in frame_num (8.5.2). This
    also somewhat supports unintentional loss of pictures.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=745048
    https://bugzilla.gnome.org/show_bug.cgi?id=703921
    
    Original-patch-by: Wind Yuan <feng.yuan@intel.com>
    [fixed derivation of POC, ensured clone is valid for reference,
     actually fixed detection of gaps in FrameNum by PrevRefFrameNum]
    Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

commit a89a8cf1e3a0307c481510b4a43cb8f6ec96b740
Author: Wind Yuan <feng.yuan@intel.com>
Date:   Thu Feb 28 15:26:36 2013 +0800

    decoder: add utility function to clone picture objects.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=703921
    
    Signed-off-by: Wind Yuan <feng.yuan@intel.com>
    [added cosmetic changes, fixed propagation of "one-field" flag to
     children, fixed per-codec clone modes (h264)]
    Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

Gwenole,
Could you please share the video-clip from Wind?

IIRC, it's one of the conformance test streams and the patches suggested here did not fix that since it was already fixed some time ago. Need to find out that old e-mail with the reference.

+ the post 0.6.0 bits are now in for 0.6.1.

commit 52adebe779240d1b1fe942176b1b6d81b1ea7154
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Mon Jun 29 14:27:56 2015 +0200

    decoder: h264: track previous reference frames.
    
    Improve closure of gaps in frame_num by strictly following and trying
    to fill them with previous reference frames. So, they are now tracked
    thus avoiding insertion of dummy ("greenish") frames.

commit 06147100f263c35f418e971361672d4a73c00ebf
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Mon Jun 29 13:16:09 2015 +0200

    decoder: h264: fix integration of second field into the DPB.
    
    If the new picture to be added to the DPB is not a first field, then
    it shall be the second field of the previous picture that was added
    before.
    
    This removes the need for dpb_find_picture() now that we track the
    immediately preceding decoded picture, in decode order.

commit d4ccae8398c4971c9400473b1a8a1308f7ea1ea8
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Mon Jul 6 14:38:26 2015 +0200

    decoder: h264: fix closure of "other-field" gap.
    
    When a dummy "other-field" is inserted, it is assumed to inherit the
    reference flags from the first field, and the sliding window decoded
    reference picture marking process is also executed so that corrupted
    frames are moved out as early as possible.
    
    While doing so, we also try to output frames that now contain a single
    valid field picture, prior to inserting any other picture into the DPB.
    Note: this may be superfluous currently based on the fact that dpb_add()
    combines the two most recent pairable fields, but this process would be
    further simplified later on.

commit 80a7ab09591474d20e158f774d50ce1e5c32d35e
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Wed Jun 24 13:58:17 2015 +0200

    decoder: h264: track corrupted frames.
    
    Mark the picture as "corrupted" if it is reconstructed from corrupted
    references or if those references are fake, e.g. resulting from lost
    frames.
    
    This is useful for notifying the upper layer, or downstream elements,
    that the decoded frame may contain artefacts.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=703921