can we put this bug as high priority, since it impacts many cases?

Marked as critical.

Gwenole, have you looked into this one?

Sri, Gwenole - any comment here?

The six clips in the above list:
BA1_FT_C.264
CANL1_TOSHIBA_G.264
CAWP1_TOSHIBA_E.264
CI1_FT_B.264
CVWP1_TOSHIBA_E.264
CVWP3_TOSHIBA_E.264

passed since the patch e52d394b9e1e7124a141cc26675068e6fc2446a9 applied;
commit e52d394b9e1e7124a141cc26675068e6fc2446a9
Author: Gwenole Beauchesne 
Date: Tue Feb 4 18:35:28 2014 +0100

decoder: h264: fix robustness patch for bytestream format.

commit 5a3e51472d7dd8fd1c5d1e87cf0c73c58a476498
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Fri Apr 25 19:11:03 2014 +0200

    decoder: h264: fix activation of picture and sequence parameters.
    
    At the time the first VCL NAL unit of a primary coded picture is found,
    and if that NAL unit was parsed to be an SPS or PPS, then the entries
    in the parser may have been overriden. This means that, when the picture
    is to be decoded, slice_hdr->pps could point to an invalid (the next)
    PPS entry.
    
    So, one way to solve this problem is to not use the parser PPS and
    SPS info but rather maintain our own activation chain in the decoder.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=724519
    https://bugzilla.gnome.org/show_bug.cgi?id=724518

commit 3a6f6f97ab956709d2dfa1b12ea221ecabdcb1ce
Author: Zhong Cong <congx.zhong@intel.com>
Date:   Tue Jun 4 15:01:46 2013 +0800

    decoder: h264: skip SPS extension and auxiliary slice NALs.
    
    When NAL units of type 13 (SPS extension) or type 19 (auxiliary slice)
    are present in a video, decoders shall perform the (optional) decoding
    process specified for these NAL units or shall ignore them (7.4.1).
    
    Implement option 2 (skip) for now, as alpha composition is not
    supported yet during the decoding process.
    
    This fixes decoding of the primary coded video in alphaconformanceG.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=703928
    https://bugzilla.gnome.org/show_bug.cgi?id=728869
    https://bugzilla.gnome.org/show_bug.cgi?id=724518
    
    [skip NAL units earlier, i.e. at parsing time]
    Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

commit fac59d6fcfed35ea0ff400ec33d0001172057c06
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Sat Apr 26 20:21:46 2014 +0200

    decoder: h264: fix initialization of RefPicLists for multiple slices.
    
    The initialization of reference picture lists (8.2.4.2) applies to all
    slices. So, the RefPicList0/1 lists need to be constructed prior to
    each slice submission to the HW decoder.
    
    This fixes decoding of video sequences where frames are encoded with
    multiple slices of different types, e.g. 4 slices in this order I, P,
    I, and P. More precisely, CABAST3_Sony_E and CABASTBR3_Sony_B.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=724518

commit e95a42ea6e9e7235623c71ea2aa2b13c92380ac2
Author: Cong Zhong <congx.zhong@intel.com>
Date:   Fri May 24 19:00:54 2013 +0800

    decoder: h264: fix long-term reference picture marking process.
    
    Fix reference picture marking process with memory_management_control_op
    set to 3 and 6, i.e. assign LongTermFrameIdx to a short-term reference
    picture, or the current picture.
    
    This fixes decoding of FRExt_MMCO4_Sony_B.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=64624
    https://bugzilla.gnome.org/show_bug.cgi?id=724518
    
    [squashed, edited to use GST_VAAPI_PICTURE_IS_COMPLETE() macro]
    Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

commit 1b9e8a25a0a5f7e161a69a3b98303901c7bed6dc
Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Date:   Sat Apr 26 08:08:57 2014 +0200

    codecparsers: h264: fix derivation of default scaling lists.
    
    When useDefaultScalingMatrixFlag is computed to be 1 while parsing
    scaling_list(), then the scaling list shall be inferred to be equal
    to the default list (7.4.2.1.1.1). That default list is really one
    of Default_4x4_{Intra,Inter} or Default_8x8_{Intra,Inter} and not
    one from fall-back rule sets A or B.
    
    This fixes parsing for FRExt1_Panasonic_D, FRExt2_Panasonic_C,
    FRExt3_Panasonic_E and FRExt4_Panasonic_B.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=724518
    
    Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

All (168) H.264 conformance tests now pass in git master branch and results are bitexact accurate. Closing.