When the muxer is operating in VBR mode, it's kind of expected
for now that we might not put the PCR in exactly the right place,
because the muxer doesn't schedule packets that way. In that case
don't warn constantly about the PCR ending up a few ms off target.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2295>
The spec mandates this field be parsed using unsigned arithmetic. Nevertheless,
av1parser will use -1 apparently as an uninitialized value in
gst_av1_parse_frame_header. This immediately underflows last_frame_idx
though, since its type was defined as guint8. Fix this by converting to gint8.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2401>
When the sink goes from PLAYING to READY and then back to PLAYING,
the initialization of the audioclient in prepare() fails with the
error AUDCLNT_E_ALREADY_INITIALIZED. As a result, the playback
stops.
To fix this, we need to drop the AudioClient in unprepare() and
grab a new one in prepare() to be able to initialize it again
with the new buffer spec.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2096>
The functionality now resides in
gst_wasapi_util_get_device() and
gst_wasapi_util_get_audio_client().
This is a preparatory patch. It will be used in the following
patch to init/deinit the AudioClient separately from the device.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2096>
Previously one of the branches did not check for the property value. To
avoid this in the future, check inside the QoS calculation function
instead.
As a side effect this now always prints the debug messages into the logs
when samples are dropped, which is useful information even without the
QoS messages.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1224>
If a buffer is dropped during resyncing on a discont because either its
end offset is already before the current output offset of the
aggregator or because it fully overlaps with the part of the current
output buffer that was already filled, then don't just assume that the
next buffer is going to start at exactly the expected offset. It might
still require some more dropping of samples.
This caused the input to be mixed with an offset to its actual position
in the output stream, causing additional latency and wrong
synchronization between the different input streams.
Instead consider each buffer after a discont as a discont until the
aggregator actually resynced and starts mixing samples from the input
again.
Also update the start output offset of a new input buffer if samples
have to be dropped at the beginning. Otherwise it might be mixed too
early into the output and overwrite part of the output buffer that
already took samples from this input into account.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/912
which is a regression introduced by https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1180/
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1224>
failure to pass a display in 'handle' would result in uninitialized value
being returned, which would often segfault later down the road when trying
to initialize gstreamer context with it.
Check the return value of gst_structure_get() to make sure we return valid
data.
Furthermore, the gstglimagesink in gst-plugins-base also has a similar
mechanism but uses 'display' as field name to pass the value; instead of
requiring the application to behave differently depending on what sink
was automatically detected just try to read both values here, with display
being the new default.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2292>
Use of subframe API from videodecoder base class.
This subframe allows to decode subframe instead of
waiting for a whole frame.
The subframe uses the same frame over the whole
subframe passing process and will wait
for a signal to know the last subframe.
In this implementation it will use
GST_VIDEO_BUFFER_FLAG_MARKER as the
end of batch of subframes.
This implement subframe mode negotation for the Zynq based on caps
negotation. This mode can be combined with low-latency mode, in order to
reach the lowest possible latency (assuming the stream is within the
low-latency constraints for the HW).
... ! video/x-h264,alignment=nal ! omxh264dec ! ...
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-omx/-/merge_requests/49>
The current setting of color properties are not very correct and
we will get some kind of "unknown Color Standard for YUV format"
warnings printed out by drivers. The video-color already provides
some standard APIs for us, and we can use them directly.
We also change the logic to: Finding the exactly match or explicit
standard first. If not found, we continue to find the most similar
one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2385>
A video decoder can now receive subframes and start decoding
instead of waiting for the full frame to be complete.
Subframe support will reduce latency as described in the
video encoder base class.
A unit test illustrating this API is available in
tests/check/libs/videodecoder.c.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/454>
if there is no pad name, the representation id
was NULL, causing a crash when writing the mpd file.
gst-launch-1.0 videotestsrc num-buffers=900 ! video/x-raw, width=800,
height=600, framerate=30/1 ! x264enc ! video/x-h264, profile=high !
dashsink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2064>
There may be leading frames after the IRAP frames, which has negative
POC. This kind of frames are allowed and they will be displayed before
the IRAP frame. So the warning should not be triggered for them. Init
the last_output_poc to G_MININT32 can avoid this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2380>
There may be leading frames after the IDR frame, which has negative
POC. This kind of frames are allowed and they will be displayed before
the IDR frame. So the warning should not be triggered for them. Init
the last_output_poc to G_MININT32 can avoid this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2380>
Instead of using the new "application/x-cbcs" caps, we are just adding
a new structure field "ciphe-mode", to indicate which encryption scheme
is used: "cenc", "cbcs", "cbc1" or "cens".
Similarly for the protection metadata, we add the "cipher-mode" field
to specify the encryption mode with which the buffers are encrypted.
"cenc": AES-CTR (no pattern)
"cbc1": AES-CBC (no pattern)
"cens": AES-CTR (pattern specified)
"cbcs": AES-CBC (pattern specified, using a constant IV)
Currently only "cenc" and "cbcs" are supported.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1013>
