Previously pads might have been requested already (e.g. in NULL state),
then reset was called (e.g. because changing state) and then a new pad
was requested. Resetting is re-creating the internal muxer object and as
such resetting the pid counter, so the next requested pad would get the
same pid as the first requested pad which then leads to collisions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2317>
As per SDK doc, IDeckLinkInputCallback::VideoInputFrameArrived
method might not provide video frame and it can be null.
In that case, given stream_time can be invalid.
So, we should not try to convert GST_CLOCK_TIME_NONE
by using gst_clock_adjust_with_calibration()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2337>
Track kernel and VA driver dependencies so gstreamer
will re-inspect the plugin if any of them change.
Also, do not blacklist the plugin if !msdk_is_available
since it could be a transient issue caused by one or
more external dependency issues (e.g. wrong/missing
driver specified, but corrected by user later on).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2335>
Some decoder implementations might drain out internal buffers and
reset its status on segment-done event. So, in case that
upstream stream-format is packetized but downstream supports only
byte-format, required codec-data might not be forwarded toward
downstream if such parameter set NAL units don't exist in inband
bitstream. Therefore, parse elements should re-send parameter set NAL
units like the case of flush event.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2334>
We add 12 bits entries into this default mapping. And the old mapping
is not precise. For example, the NV12 should not be used as the default
mapping for VA_RT_FORMAT_YUV422 and VA_RT_FORMAT_YUV444, it is even not
a 422 or 444 format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2332>
For those using context from the application which
would be the embedded video case, if the frame callback
is entering at the same time as window is finalizing,
a wayland proxy object would be destroyed twice, leading
the refcout less than zero in the second time, it can
throw an abort() in wayland.
For those top window case, which as a directly connection
to the compositor, they can stop the message queue then
the frame callback won't happen at the same time as the
window is finalizing. It doesn't think it would bother
them about this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1883>
alphacombine element is a simple element that assumes buffers are always
paired, or at least that missing buffers are signalled with a GAP. The QoS
implementation in the GstVideoDecoder base class allow decoders dropping
frames independently and that could lead to stall in alphacombine.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2326>
We always get a warning such as:
h265decoder gsth265decoder.c:1432:gst_h265_decoder_do_output_picture: \
<vah265dec0> Outputting out of order 255 -> 0, likely a broken stream
in H265 decoder.
The problem is caused because we fail to reset the last_output_poc when
we get IDR and BLA. The incoming IDR and BLA frame already bump all the
frames in the DPB, but we forget to reset the last_output_poc, which
make the POC out of order and generate the warning all the time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2294>
There are a few places which require deep copy
(basesink on drain for example). Also this implementation can be
useful for future use case.
One probable future use case is that copying DPB texture to
another texture for in-place transform since our DPB texture is never
writable, and therefore copying is unavoidable.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2308>
... based on MediaFoundation work queue API.
By this commit, wasapi2 plugin will make use of pull mode scheduling
with audioringbuffer subclass.
There are several drawbacks of audiosrc/audiosink subclassing
(not audiobasesrc/audiobasesink) for WASAPI API, which are:
* audiosrc/audiosink classes try to set high priority to
read/write thread via MMCSS (Multimedia Class Scheduler Service)
but it's not allowed in case of UWP application.
In order to use MMCSS in UWP, application should use MediaFoundation
work queue indirectly.
Since audiosrc/audiosink scheduling model is not compatible with
MediaFoundation's work queue model, audioringbuffer subclassing
is required.
* WASAPI capture device might report larger packet size than expected
(i.e., larger frames we can read than expected frame size per period).
Meanwhile, in any case, application should drain all packets at that moment.
In order to handle the case, wasapi/wasapi2 plugins were making use of
GstAdapter which is obviously sub-optimal because it requires additional
memory allocation and copy.
By implementing audioringbuffer subclassing, we can avoid such inefficiency.
In this commit, all the device read/write operations will be moved
to newly implemented wasapi2ringbuffer class and
existing wasapi2client class will take care of device enumeration
and activation parts only.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2306>
This is a video specific sink used to test video CODEC conformance. This is similar
to a combination of filesink and testsink, but will skip over any type of
padding that GStreamer Video library introduces. This is needed in order to obtain the
correct checksum or raw yuv data.
This element currently support writing back non-padded raw I420 through the
location property and will calculate an MD5 and post it as an element message
of type conformance/checksum. More output format or checksum type could be
added in the future as needed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2287>
