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>
If a property is supplied to gst-launch-1.0 to set on a property that
implements GstChildProxy, it would always accept any property name
and try to set it later. This means that (for example) decodebin
will accept and not complain about property names that can never exist like:
gst-launch-1.0 videotestsrc ! decodebin NON-EXISTING_PROPERTY=adsfdasf ! fakesink
Instead, only try to do deferred property setting for property names
that contain the :: separator that indicates it's a setting on a child
that might appear later.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/832>
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>
Updating of codec_data in the caps is important to propagate changes
in sps/pps/vps via NALs. Without this, downstream does not renegotiate
when upstream changes resolution.
The comment referring to rtph264pay is from 2015 and is out of date.
rtph264pay stopped doing that in 2017 with commit
dabeed52a9
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1011>
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>
below commit change the window resize thread and cause viv-fb backend
hang, need move resize code after window->open is called. Otherwise,
the resize message will send to a thread that not start running and
window resize call will waiting forever.
Commit: b887db1efe
glwindow: fix racy resize updates
Take locks around resize handling and marshall all resizes to the
windowing thread by default.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1195>
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>
