In 2018 khronos changed the gl header guards. If we don't detect
this properly we would end up with plenty of symbol redifinition
(since we would be importing twice the "same" header).
Instead detect if the "newer" header was already included and if
so define the "old" define to avoid this situation
Fixes#523
When the EOS event is received, run all timers immediately and avoid
pushing the EOS downstream before this has been run. This ensures that
the lost packet statistics are accurate.
The teardown of the pads checks the refcount, but there are timers
inside the jitterbuffer that can push things, so if we're not lucky,
things could be pushed while the pads are being shut down. Putting the
jitterbuffer to NULL first avoids this.
After EOS is received, it is pointless to wait for further events,
specially waiting on timers. This patches fixes two cases where we could
wait instead of returning GST_FLOW_EOS and trigger a spin of the loop
function when EOS is queued, regardless if this EOS is the queue head or
not.
Pull in video frame fields into local variables. Without this the
compiler must assume that they could've changed on every use and read
them from memory again.
This reduces the inner loop from 6 memory reads per pixels to 4, and the
number of writes stays at 3.
stream.segment should be updated with the values of the current edit
list, also when a new `moov` is received. Unfortunately this was not
being the case because of an early return.
As a consequence of this bugs, no end of movie clipping was being
performed on the new moov and no segment event was being emitted.
When performing stream switching (e.g. in MSE) the new moov may have a
different edit list. This is often the case when switching between
baseline H.264 (which lacks B-frames) and more demanding profiles. For
this reason it's important to emit a new segment in order to be able
to get matching stream times.
This patch moves the initialization of QtDemuxStream.segment from
gst_qtdemux_add_stream() to _create_stream(). This ensures the segment
is always initialized when the stream is created.
Otherwise the segment format is left as GST_FORMAT_UNDEFINED in the case
were a track is reparsed and qtdemux_reuse_and_configure_stream() is
called instead of gst_qtdemux_add_stream(). (See
qtdemux_expose_streams() in the non streams-aware case.)
This is an extra internal recurisve lock use to avoid having to take
both sink pad streams lock all the time. This patch renamed it
INTERLNAL_STREAM_LOCK/UNLOCK() to avoid confusion with possible upstream
GST_PAD API.
This reverts "6f3734c305 rtpssrcdemux: Only forward stick events while
holding the sinkpad stream lock" and actually hold on the internal
stream lock. This prevents in some needed case having a second
streaming thread poping in and messing up event ordering.
While forwarding serialized event, we use gst_pad_forward() function.
In the forward callback (GstPadForwardFunction) we always return
TRUE. Returning true there will stop the dispatching procedure. As a
side effect, only one events is receiving the events. This breaks
when sending EOS from the applicaiton, it also breaks the latency
tracer.
The previous patch did not even compile on any possible platform or C
standard. That commit also didn't have a proper commit message.
Android ships Linux with a different signature for ioctl. They first
released an ioctl with int as request type, and later "fixed" it by
adding an override with unsign, which is still not matching Linux and
BSD implementation which uses unsigned long int.
PulseAudio defines PA_RATE_MAX as the maximum sampling rate that it
supports. We were previously exposing a maximum rate of INT_MAX, which
is incorrect, but worked because nothing was really using a rate greater
than 384000 kHz.
While playing DSD data, we hit a case where there might be very high
sample rates (>1MHz), and pulsesink fails during stream creation with
such streams because it erroneously advertises that it supports such
rates.
Since PA_RATE_MAX is #define'd to (8*48000U), we can't just use it in
the caps string. Instead, we fix up the rate to what we actually support
whenever we use our macro caps.
This patch enables matroskademux to receive seeks before it reaches
GST_MATROSKA_READ_STATE_DATA.
Closes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/514
This also enables receiving seeks in the element READY state.
When such a seek is received, it is stored to be later handled when
GST_MATROSKA_READ_STATE_DATA is reached.
Reset RTPSession when rtpsession changes state from PAUSED to READY.
Without this change, a stored last_rtptime in RTPSource could interfere
with RTP timestamp generation in RTCP Sender Report.
Fixes#510
This commit adds a .gitlab-ci.yml file, which uses a feature
to fetch the config from a centralized repository. The intent is
to have all the gstreamer modules use the same configuration.
The configuration is currently hosted at the gst-ci repository
under the gitlab/ci_template.yml path.
Part of https://gitlab.freedesktop.org/gstreamer/gstreamer-project/issues/29
If there was no interlace-mode field in the caps. Read back the value
selected by the driver. This way, if the driver does not support
progressive, then it will automatically negotiate the returned mode
unless this mode is not supported by GStreamer.
This method was already used for colorimetry. Just like colorimetry, the
interlace mode is not longer probed by v4l2src dues to performance
issues.
Fixes#511
