If the mutex is locked while running frameComplete there is a potential deadlock
bound to happen when we get a new exported images from the backend.
Fixes#1101
This allows selecting whether we continue updating our last known
upstream timecode whenever a new one arrives or instead only keep the
last known one and from there on count up.
This uses the last known upstream timecode (counted up per frame), or
otherwise zero if none was known.
The normal last-known timestamp uses the internal timecode as fallback
if no upstream timecode was ever known.
Commit 8a56a7de6d (camerabin2: preview:
Appsink doesn't need to sync) add a line that set the "sync" property on
the appsink. However, the author seems to forget that there's another
property setting on appsink a few lines below.
It's very likely that the added line is required because the original
line doesn't take effect (maybe because it's too late). But for whatever
reason, the original line is now redundant. So, I remove it in this
commit.
GstTranscoder adds extra_args for gir which call gst_init() during
introspection. These extra arguments are the same as the standard
ones defined in the top level meson.build as "git_init_section",
However, the top level definition also ensures an empty plugin
repository is used.
Because GstTranscoder does not use the standard args, plugins get
loaded when it is introspected. Since some of the plugins fail
without specific hardware, this causes #1100.
This patch makes it use gir_init_section.
Fixes#1100.
This can be made to work in certain circumstances when
cross-compiling, so default to not building g-i stuff
when cross-compiling, but allow it if introspection was
enabled explicitly via -Dintrospection=enabled.
See gstreamer/gstreamer#454 and gstreamer/gstreamer#381.
Upon bitrate change, make sure to close the encoder otherwise
the encoder is not re-initialized and the target bitrate is
never reached, and the encoder was flushed at each frame
from this moment.
Regression introduced in f2b35abcab which replaced the call
that was closing the encoder by an early return to avoid
re-initialization.
gstwasapiutil.c(173) : warning C4715: 'gst_wasapi_device_role_to_erole': not all control paths return a value
gstwasapiutil.c(188) : warning C4715: 'gst_wasapi_erole_to_device_role': not all control paths return a value
The GstDeviceProvider isn't subclass of GstElement.
(gst-device-monitor-1.0:49356): GLib-GObject-WARNING **: 20:21:18.651:
invalid cast from 'GstWasapiDeviceProvider' to 'GstElement'
Some hardware decoders, for example Hantro G1, have to be told the
size of the pic_order_cnt related syntax elements pic_order_cnt_lsb,
delta_pic_order_cnt_bottom, delta_pic_order_cnt[0], and
delta_pic_order_cnt[1] in bits.
Some hardware decoders, for example Hantro G1, have to be told the size
of the dec_ref_pic_marking() syntax element in bits. Record the size so
it can be passed on to the hardware.
The calculated size of short_term_ref_pic_set is not a part of
HEVC syntax but the value is used by some stateless decoders
(e.g., vaapi, dxva, vdpau and nvdec) for the purpose of skipping
parsing the syntax by the accelerator.
Add num_ref_idx_active_override_flag and sp_for_switch_flag to
member of GstH264SliceHdr. No reason to hiding them and
some decoder implementations (e.g., DXVA) rely on externally parsed header
data which can be provided by h264parser.
The first channel in memory for MFX_FOURCC_RGB4 (VA_FOURCC_ARGB or
GST_VIDEO_FORMAT_BGRA) is B, not A. In MSDK, channle B is used to access
data for RGB4 surface. In addition, the returned pointers for
MFX_FOURCC_AYUV and MFX_FOURCC_Y410 in gst_msdk_video_memory_map_full
were wrong too before this fix.
When the bitrate is changed in playing state the encoder issues a reconfig
that drains and recreates the underlaying hw encoder instance.
With this set of changes we ensure that all this work is only made when
the bitrate did actually change. It also tries to reuse the vpp buffer
pool and fixes the pool leak spotted when testing this feature.
hlssink2 defined "max-files" property to decide the maximum number
of fragments which should be stored in disk. But we've not used
the property. Instead, the size has been maintained by "playlist-length".
Since "max-files" and "playlist-length" have different meaning,
the decision should be done by "max-files" property.
For example, an user might want expose only 3 fragments via playlist
but might want to keep more files than 3 in disk.
A classic case of not updating the next item to iterate after deleting
it from the singly linked list.
Only ever hit with a text buffer with GST_CLOCK_TIME_NONE for either the
timestamp or duration.
hlssink* elements could be finalized without EOS event, and in that case
the final playlist might not include the EXT-X-ENDLIST tag.
Since missing ENDLIST tag means it's live stream, but we did't intend it,
hlssink* elements should put the tag at the end.
When postpone_free_surface is TRUE, the output buffer is not writable,
however the base decoder needs a writable buffer as output buffer,
otherwise it will make a copy of the output buffer. As the underlying
memory is always lockable, so we may set the LOCKABLE flag for this buffer
to avoid buffer copy in the base class.
The refcount of the output buffer is 1 when postpone_free_surface is
FALSE, so needn't set the LOCKABLE flag for this case.
