Applications might handle locations and generally configuration of the
sink by themselves instead of having splitmuxsink set the location on
the sink. Nonetheless it makes sense to increment the fragment_id that
is passed to the signal so that applications know which fragment is
requested.
If Mesa is built without X11 headers, building against Mesa EGL headers
requires a dependency on egl.pc, to define MESA_EGL_NO_X11_HEADERS.
This fixes a build error when compiling ext/qt/gstqtglutility.cc:
In file included from /usr/include/EGL/egl.h:39,
from /usr/include/gstreamer-1.0/gst/gl/egl/gstegl.h:44,
from ../gst-plugins-good-1.16.1/ext/qt/gstqtglutility.cc:43:
/usr/include/EGL/eglplatform.h:124:10: fatal error: X11/Xlib.h: No such file or directory
Add parsed=true to output caps, as we always output
whole frames, timestamped and all. Means also that
the output can be decoded by avdec_mjpeg wihout
plugging an extra parser (which has no rank).
This was never installed and it was only used by the uninstalled
autotools dev environment to locate the -good plugins for use
in unit tests in gstreamer modules higher up the stack.
It is no longer needed now that we no longer have an autotools build.
Add a property that makes it possible for an application to set the
DateUTC header field in matroska files. This is useful for live feeds,
where the DateUTC header can be set to a UTC timestamp, matching the
beginning of the file.
Needs gstreamer!323
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/481
Before we do streamon, we queue all capture buffers by calling
resurrect. When the driver supports CREATE_BUFS, this would lead
to buffers being allocated till the maximum of 32 is reached.
Instead, we now save the number of allocated buffers and queue this
amount.
libv4l2 reset the colorpace to 0 and does not do any request to the
driver. This yields an invalid colorspace which currently cause a
negotiation failure. This workaround by ignoring bad values during the
TRY_FMT step.
An application might try to access splitmuxsink from sync message handler
by g_object_{get,set} which takes lock also. In general, we don't
take lock around message handler.
By passing `NULL` to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
The do_expected_timeout() function may release the JBUF_LOCK, so we need
to check if nothing wanted the timer thread to exit after this call.
The side effect was that we may endup going back into waiting for a timer
which will cause arbitrary delay on tear down (or deadlock when test
clock is used).
Fixes#653
JBUF_WAIT_QUEUE drops the JBUF_LOCK, which means the stop condition
for the chain function may have changed (change_state to NULL). Check
this immediately after the wait so that we don't delay shutting down.
When in-place, running an allocation is not useful since videocrop
is not implicated in the allocation. So only force the allocation
query for the case it was in passthrough. This is needed since the
change in the crop region will likely pull us out of this mode. For the
case we where neither in passthrough or in-place, the allocation query
is already ran by the baseclass, so nothing special is needed.
This fixes performance issues when changing the crop region per frame.
This was reproduced using videocrop2-test.
If the the height is not a multiple of the macro block size then the memory
of the last line is reused for all extra lines. This is no problem if the
last line is duplicated properly. However, if the extra lines are not
initialized properly during encoding, then the last visible line is
overwritten with undefined data.
Use a extra buffer to avoid this problem.
One of the jitterbuffers functions is to try and make sense of weird
network behavior.
It is quite unhelpful for the jitterbuffer to start dropping packets
itself when what you are trying to achieve is better network resilience.
In the case of a skew, this could often mean the sender has restarted
in some fashion, and then dropping the very first buffer of this "new"
stream could often mean missing valuable information, like in the case
of video and I-frames.
This patch simply reverts back to the old behavior, prior to 8d955fc32b
and includes the simplest test I could write to demonstrate the behavior,
where a single packet arrives "perfectly", then a 50ms gap happens,
and then two more packets arrive in perfect order after that.
# Conflicts:
# tests/check/elements/rtpjitterbuffer.c
Try configuring the v4l2 output with the alignments from upstream when
importing its buffers. This allows us to support importing with
non-standard strides and/or heights if supported by the driver.
We were already supporting horizontal padding by setting bytesperline to
the buffer stride but not vertical one.
We are now updating the format height with the padded height and crop to
the actual video resolution if needed.
In commit e2ff87732d ("v4l2videodec: support orphaning") support for
orphaning the capture buffer pool was added when the format is
renegotiated. However, the commit forgot to check that a pool existed
before doing this. This is needed because it's possible for the format
to be renegotiated before a capture pool is allocated, which would
result in trying to orphan a NULL pool and lead to a NULL pointer
dereference.
Fix this by checking a pool exists first. If the pool doesn't exist,
there are no buffers to be reclaimed, so skip the allocation query in
that case.
The memory leak occurs in the case when the buffer has been
added to the fragment_buffers array of the current pad and
never been sent because of the push failure of the previous
buffers: moof or mdat header or fragmented buffer(s).
