h264: support process for gaps in frame_num

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".

Because the driver needs to test the effectiveness
of the picture, dummy picture needs a surfaceID.
And according to the provisions of spec, the dummy
pictures is not used for reference,so surfaceID of
current picture is set to the dummy picture.

Signed-off-by: Zhong Cong <congx.zhong@intel.com>
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>
Signed-off-by: Zhong Cong <congx.zhong@intel.com>
vaapidisplay: init version, abstract for VADisplay
vaapicontext: init version, abstract for VaContext
decoder: uses vaapicontext
picture: uses vaapicontext