User reported MFX_VERSION is 1026 however the build is broken[1], so add
the check for mfxExtVP9Param to make sure it can be build without
compiler error.

In addtion, it fixes a stupid typo (#endif') introduced by me.

[1] !988 (comment 408093)

s/milisecs/milliseconds/g

Some mpeg-ts (HLS, DVB, ...) streams out there have completely broken
PCR streams on which we can't reliably recover correct timestamps.

For those, provide a property that will ignore the program PCR stream
(by faking that it's not present (0x1fff)).

Some MPEG-PS streams might not be compliant but the SCR can be ignored
if PTS/DTS in PES header is consistently increased.

Do not pass SPS nal_unit_type (0x67) into gst_h264_parse_sps()

Fixes #648

Apply in-band sps/pps resending implementation to h265parse.

Initially the case "only codec_data is different" was addressed in
https://bugzilla.gnome.org/show_bug.cgi?id=705333 in order for
unusual bitstreams to be handled. That's the case where sps and pps
are placed in bitstream. When sps/pps are signalled only via caps
by upstream, however, the updated codec_data is mandatory for decoder
and therefore we shouldn't ignore them.

According to following spec document, add format_identifier for AC4 in tsdemux.

ETSI TS 103 190-2 V1.2.1 : Annex D : AC-4 in MPEG-2 transport stream

According to following two specs, add support for AC4 in tsdemux.

1. ETSI TS 103 190-2 V1.2.1 (2018-02) : Annex D (normative): AC-4 in MPEG-2 transport streams
2. ETSI EN 300 468 V1.16.1 (2019-08) : Annex D (normative):Service information implementation of AC-3, EnhancedAC-3, and AC-4 audio in DVB systems

The ICE gathering state can transition to complete prematurely if the
underlying ICE components complete their gathering while the initial
ICE gathering state task is queued and still pending.

In that situation, the ice gathering state task will report complete
while there are still ICE candidates queued for emission.

Prevent that by storing ICE candidates in an array and checking if
there are any pending before reporting a completed ICE gathering
state.

ICE candidates can be added to the array directly from the application
or from the webrtc main loop. Rename it to make it clear that it's
holding remote ICE candidates from the peer, and protect it with a
new mutex

VP9 codec allows resizing reference frame by spec. Handling this case
is a bit tricky especially when the resizing happens on non-keyframe,
because pre-allocated decoder textures (i.e., dpb) have negotiated
resolution and to change resolution meanwhile decoding on non-keyframe,
each texture might need to be re-created, copied to new dpb somehow,
and re-negotiated with downstream.

Due to the complicated requirement of negotiation driven
resizing handling, this commit adds shader into d3d11decoder object
to resize only corresponding frames. Note that if the resolution change
is detected on keyframe, decoder will re-negotiate with downstream.

To copy decoder output texture to another d3d11 texture, the downstream
texture needs to be aligned too.

Not only any textures for decoder output view, any destination texture
which would be copied from decoder output texture need to be aligned too.
Otherwise driver sometimes crashed/hung (not sure why).

Vertex buffer will be updated if input texture resolution is different
from GstVideoInfo or when an user requests specific crop area.

Resolution of NV12, P010, and P016 formats must be multiple of two.
Otherwise texture cannot be created. Instead of doing this alignment
per API consumer side, do this in buffer pool for simplicity.

same as we are doing in h264decoder

Most likely this modification can save GPU memory.

Scaling list can be signalled via sps or pps. Decoder should check
both of them.

ucNumDeltaPocsOfRefRpsIdx should be the NumDeltaPocs[RefRpsIdx].

That's the value of NumDeltaPocs[RefRpsIdx] and we might be able to derive
the value from given sps and slice header.
Because well known hardware implementations refer to the value, however,
storing the value makes things easier.

Following is the list of hardware implementations
* DXVA2: ucNumDeltaPocsOfRefRpsIdx
* NVDEC/VDPAU: NumDeltaPocsOfRefRpsIdx

See C.5.2.2 Output and removal of pictures from the DPB.

If the number of pictures in the DPB is greater than or equal to
sps_max_dec_pic_buffering_minus1[HighestTid] + 1, then the picture
should be outputted.

This library is not intended to be public. APIs are likely to
change over time and should not be disclosed to people yet.

No more a part of d3d11 implementation

s/GstH264Picture/GstVp9Picture/g and minor update since this baseclass
is no more d3d11 specific one.

GstVideoCodecFrame is expected to be consumed by subclass
per output_picture(). So the implementation cannot be optional.

... and remove namespaceless macro methods from baseclass

Add some macros to remove code duplication and to make it more readable

By just letting GStreamer choose a good name

Now that the system_frame_number is saved on the pictures we can use
gst_video_decoder_get_frame() helper instead of getting the full list
and looping over it.

This allow cross-referencing GstH264Picture and GstVideoCodecFrame.

Some of the syntax element do not use the spec name, which makes them harder
to find in the spec.

On new_segment, the decoder is expected to negotiate. The decoder may want to
pre-allocate the needed buffers. Pass the max_dpb_size as this is needed to
determin how many buffers should be allocated.