GitLab

When expose() is called, d3d11videosink needs to redraw using
cached buffer, so gst_d3d11_window_render() should allow null buffer.

Part-of: <gstreamer/gst-plugins-bad!2450>

Current implementation for translating native coordinate and
video coordinate is very wrong because d3d11videosink doesn't
understand native HWND's coordinate. That should be handled
by GstD3D11Window implementation as an enhancement.

Part-of: <gstreamer/gst-plugins-bad!2450>

Inspired by an MR gstreamer/gst-plugins-bad!2382

The idea is that we can make use of MoveWindow() in WIN32 d3d11window
implementation safely because WIN32 d3d11window implementation creates
internal HWND even when external HWND is set and then subclassing is used to
draw on internal HWND in any case. So the coordinates passed to MoveWindow()
will be relative to parent HWND, and it meets well to the concept of
set_render_rectangle().

On MoveWindow() event, WM_SIZE event will be generated by OS and then
GstD3D11WindowWin32 implementation will update render area including swapchain
correspondingly, as if it's normal window move/resize case.

But in case of UWP (CoreWindow or SwapChainPanel), we need more research to
meet expected behavior of set_render_rectangle()

Fixes: gstreamer/gst-plugins-bad#1416
Part-of: <gstreamer/gst-plugins-bad!2450>

The gint8 of qi and qi_base may overflow when calculation the matrix
parameters and change the decoding result.

Part-of: <!2447>

Direct3D11 sampler doesn't support them very well, and conversion
outputs usually result in poor visual quality with our shader code.
Should disable support for such formats for now

Part-of: <!2344>

Part-of: <!2437>

While a cc_data_pkt with cc_valid 0 should be considered padding,
it might be followed up by valid DTVCC packets, and should not
cause the whole CDP packet to get discarded.

Part-of: <!2440>

We need to consider the first field of the last picture when the
last picture can not enter the DPB.

Another change is, when prev field's frame_num is not equal to the
current field's frame_num, we should also return FASLE because it
is also a case of losing some field.

Part-of: <!2430>

There are cases that the first field of the last picture is not a
ref but the second field is a ref. We need to add both of them
because the bumping always needs a complete frame in the DPB.

Part-of: <!2430>

For interlaced streams, it is also possible that the last frame is
not able to be inserted into DPB when the DPB is full and the last
frame is a non ref. For this case, we need to hold a extra ref for
the first field of the last frame and wait for the complete frame
with both top and bottom fields. For the progressive stream, the
behaviour is unchanged.

Part-of: <!2430>

When the dpb is interlaced, the max size should be 2*dpb->max_num_frames,
correcting the error print info for that.

Part-of: <!2430>

This is not a fatal error on systems without decklink

Part-of: <!2441>

Part-of: <!2439>

Part-of: <!2433>

The needed once call was removed accidently during porting. This was catch by
the CI as memory leaks.

Related to !2426

Part-of: <!2438>

Fixes #80

Part-of: <!2436>

The idea of this change is to add, in the future,
process_with_generator(), when multiple input surfaces are processed,
for blending.

Part-of: <!2431>

Part-of: <!2431>

vapostproc will not call gst_buffer_pool_config_set_video_alignment(),
thus this option is not required.

Part-of: <!2431>

We can now handle this fine

Part-of: <!2434>

When reaching the end of non-frame wrapping track in pull mode, we want to force
the switch to the next non-eos pad. This is similar to when we exceed the
maximum drift.

Fixes issues on EOS where not everything would be drained out and stray errors
would pop out.

Part-of: <!2434>

An interleave of 500ms can be way too big for some downstream queueing
elements. Instead use a smaller 100ms interleave and silence the various
warnings about resyncing (it's normal)

Part-of: <!2434>

Part-of: <!2426>

Adds a new plugin for ASIO devices.

Although there is a standard low-level audio API, WASAPI, on Windows,
ASIO is still being broadly used for audio devices which are aiming to
professional use case. In case of such devices, ASIO API might be able
to show better quality and latency performance depending on manufacturer's
driver implementation.

In order to build this plugin, user should provide path to
ASIO SDK as a build option, "asio-sdk-path".

Part-of: <!2309>

... for user to be able to set the number of required samples.
For instance, our default value is 240 samples
(about 5ms latency in case that sample rate is 48000), which might
be larger than actual buffer size of audio capture device.

Part-of: <!2307>

The print_ref_pic_list_b now not only needs to trace the ref_pic_list_b0/1,
but also need to trace the ref_frame_list_0_short_term. We need to pass the
name directly to it rather than an index to refer to ref_pic_list_b0/1.

Part-of: <!2425>

The array sort of ref_frame_list_0_short_term has some typo. The
typo makes this list not in the POC ascend order and generate wrong
decoding result for interlaced streams.

Part-of: <!2425>

When driver return error on update plane request, kmssink
disables the scaling and retries plane update.
While doing so kmssink was matching the source rectangle dimensions
to the target rectangle dimensions which were calculated
as per scaling but this is incorrect, instead what we want here is
that target rectangle dimensions should match the source rectangle
dimensions as scaling is disabled now and so we match result
rectangle dimensions with source rectangle dimensions.

While at it, also match the result rectangle coordinates for
horizontal and vertical offsets with source rectange coordinates,
as since there is no scaling being done so no recentering is
required.

Part-of: <!2415>

Some cut VP9 streams begin with a non key frame. The current code
just bail out the parse_process_frame() if not a key frame. Because
of this, we do not set the valid caps before we push the data of the
first frame(even this first frame will be discarded by the downstream
decoder because it is not a key frame).

The pipeline such as:
gst-launch-1.0 filesrc location=some.ivf ! ivfparse ! vp9parse !
  vavp9dec ! fakesink
will get a negotiation error and the pipeline can not continue. The
correct behaviour should be: the decoder discard the first frame and
continue to decode later frames successfully.

So, when the parse does not have valid stream info(should be the first
frame case), we should continue and report caps.

Part-of: <!2427>

pipewiresrc outputs audio buffers without a valid duration, so we need
to calculate it manually in that case.

Upstream issue: pipewire/pipewire#1438

Part-of: <!2419>

We may need to drop the slices such as RASL pictures with the NoRaslOutputFlag, so
the current picture of h265decoder may be freed. We should not assign the frame->
output_buffer too early until we really output it. Or, the later coming slices will
allocate another picture and trigger the assert of:
  gst_video_decoder_allocate_output_frame_with_params:
  assertion 'frame->output_buffer == NULL' failed

Part-of: <!2421>

Some programs specify a PCR PID but don't actually store any PCR values, or are
way too far apart.

In order to gracefully handle those situations, we will queue up to a certain
amount of pending buffers before deciding to give up on that PCR PID and not use
any (i.e. using DTS/PTS values as-is)

Fixes #1629

Part-of: <!2422>

In H265, the stream may have odd bit depth such as 9 or 11. And
the bit depth of luma and chroma may differ. For example, the
stream with luma depth of 8 and chroma depth of 9 should use the
10 bit rtformat as the decoded picture format.

Part-of: <!2420>

In low_latency mode, try to bump the picture as soon as possible
without the frames disorder:
1. We can directly output the continuous non-reference frame.
2. Consider max_num_reorder_frames, which is special useful for
   I-P mode.
3. Consider the leading pictures with negative POC.
4  Output small POC pictures when non-reference frame comes.
4. Output the POC increment<=2 pictures. This is not 100% safe,
   but in practice this condition can be used.

Part-of: <!2373>

The max_num_reorder_frames can be useful for bump check. We store it
in the DPB and no need for the decoder now.

Part-of: <!2373>

The picture->ref field will change from time to time according to decoder's
state and reference sliding window. We need another flag to record whether
the picture is a reference picture when it is created, and this can help
the bumping check.

Part-of: <!2373>

The current behavior is different from the SPEC. We should check
and bump the DPB or drain the DPB before we insert the current
picture into it. This may cause the output picture disorder.

Part-of: <!2373>

Accord to spec, we should not add the current picture into the DPB
when we check whether it needs to bump, so the checks of the IDR and
the "memory_management_control_operation equal to 5" are no needed.

And the spec also says that the DPB only needs to bump when there is
no empty frame buffer left(We handle the IDR cases in other places).
We need to follow that and the max_num_reorder_frames is useless.

We also minus 1 in has_empty_frame_buffer because the current frame
has not been added yet.

Part-of: <!2373>

Part-of: <!2373>

When current frame memory_management_control_operation equal to 5, that
means we need to drain the dpb and the current picture act as an IDR frame.
So it should have smaller poc than the later pictures to ensure the output
order.

Part-of: <!2373>