Measures the audio latency between the source pad and the sink pad by
outputting period ticks on the source pad and measuring how long they
take to arrive on the sink pad.
Very useful for quantifying latency improvements in audio pipelines.
This plugin was particularly useful during development of the
low-latency features of the wasapi plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=793839
This is a wrapper around fakesink that will advertise GstVideoMeta
and other meta API in order to achieve zero-copy whenever possible.
his new element is useful when doing performance testing with
video stream and don't want the sink capability to change the
upstream behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=793624
The pnmenc was not mapping the input buffers as video buffers. Because
of this, the video frame stride was not being set based on frame but
based on the caps, which make the assumption that the strides are a
power of 4. For input that is not a power of 4, this would lead to a
SIGSEGV.
https://bugzilla.gnome.org/show_bug.cgi?id=793419
The inter plugin originated in 0.10, which had only one timestamp. As a
result, during the port to 1.0, the DTS were left undefined. This can cause
subtle bugs with basesrc, which can end up incorrectly picking DTS over PTS
and producing output buffers with incorrect timestamps.
https://bugzilla.gnome.org/show_bug.cgi?id=791347
This keep-it-simple plugin is useful when you want to pipe arbitrary
data to a different pipeline within the same process. Some advantages
over appsink/appsrc, the inter elements, etc:
* Ease of use. Buffers, events, and caps are transmitted as-is without
copying or serialization.
* Enables zerocopy (especially DMABUF) transparently without any
special-casing.
* Enables usage with sinks or elements that are unreliable and may
throw errors and need re-initialization, such as a network sink, a
USB device sink (v4l2), etc.
* Transmits arbitrary data, not just audio/video/subs
* Can easily implement 1 producer pipeline -> N dynamic consumer
pipelines within a single process when combined with the `tee`
element.
All queries, events, buffers, and buffer lists are proxied. State
changes, clocks, and base times for the two pipelines are independent
since the upstream and downstreams continue to be different pipelines.
https://bugzilla.gnome.org/show_bug.cgi?id=788200
gdpdepay element uses the decide_allocation to fetch the downstream
allocator. Nonetheless it is possible that allocate uses a custom
alloc function, which is not usable by gdpdepay, crashing later the
application when the allocater buffer is NULL.
This patch checks for the allocator flags and reset it if the
allocator has a custom alloc function.
https://bugzilla.gnome.org/show_bug.cgi?id=789476
When querying downstream for allocation, and the source caps hasn't
set its caps, using ANY by default, it raises a critical message in
console:
CRITICAL **: gst_video_info_from_caps: assertion 'gst_caps_is_fixed (caps)' failed
This patch bails out decide_allocation() if the caps aren't fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=789476
This information could be used for example to pick a decoder supporting
a specific chroma and/or bit depth, like 4:2:2 10 bits.
It can also be used to inform earlier decoder about the format it is
about to decode.
https://bugzilla.gnome.org/show_bug.cgi?id=792039
This fixes issues where wavparse would query the file size upstream
and assert because the file size is way smaller then what the WAVE
header says. This patch disable or cane a handful of queries that
make no sense to forward.
https://bugzilla.gnome.org/show_bug.cgi?id=791811
This plugin is useful when you want to pipe arbitrary data to
a different pipeline within the same process. Buffers, events, and caps
are transmitted as-is without copying or manipulation.
"avwait-status" is posted when avwait starts or stops passing through
data (e.g. because target-timecode and end-timecode respectively have
been reached). The attached structure includes a "dropping" boolean (set
to TRUE if we are currently dropping data, FALSE otherwise), and a
"running-time" GST_CLOCK_TIME which contains the running time of the
change.
https://bugzilla.gnome.org/show_bug.cgi?id=790170
Reordering of packets is not very common in networks, and the delay
functions will always introduce reordering if delay > packet-spacing,
so by setting allow-reordering to FALSE you guarantee that the packets
are in order, while at the same time introducing delay/jitter to them.
By using the property "delay-distribution" the user can control how the
delay applied to delayed packets is distributed. This is either the
uniform distribution (as before) or the normal distribution.
"min-delay" and "max-delay" control both distributions. For the normal
distribution it defines the bounds of the 95% confidence interval.
When input is not in byte-stream format there is no need to wait for the first
buffer before setting src caps. We already have all the information from the
input codec_data.
This allow us to already configure downstream elements allowing them,
for example, to already allocate their internal buffers as they know
the format of the input they are about to receive.
Same change as the one I just did in h264parse.
https://bugzilla.gnome.org/show_bug.cgi?id=790709
When input is in AVC format there is no need to wait for the first buffer
before setting src caps. We already have all the information from the
input codec_data.
This allow us to already configure downstream elements allowing them,
for example, to already allocate their internal buffers as they know
the format of the input they are about to receive.
https://bugzilla.gnome.org/show_bug.cgi?id=790709
Try prioritizing downstream's caps over upstream's if possible so the
parser can configured in "passthrough" if possible and save it from
doing useless conversions.
Exact same change as the one I just did in h264parse.
https://bugzilla.gnome.org/show_bug.cgi?id=790628
Try prioritizing downstream's caps over upstream's if possible so the
parser can configured in "passthrough" if possible and save it from
doing useless conversions.
https://bugzilla.gnome.org/show_bug.cgi?id=790628
A deserialised timecode has a framerate of 0/1 by default. That breaks
it when comparing the frames field with another timecode (incoming from
the frame). We were setting the framerate when receiving the caps event,
but not when setting the timecode in set_property, so it was broken for
timecodes set after the caps event.
Also checking if the fps_n we got from the caps event is != 0 before
setting it - also at the caps event.
https://bugzilla.gnome.org/show_bug.cgi?id=790334
Now that timecodes support proper serialisation / deserialisation, a
timecode might have an invalid fps_n / fps_d even without using the
target-time-code-string property. Detect those cases and set fps_n/fps_d
properly.
If end_tc is NULL, it means that we don't want avwait to stop at any
timecode. When explicitly setting end_tc to NULL, there is no point in
comparing end_tc with start_tc (to see if we'll reject end_tc for being
before start_tc), so the check in question is completely disabled
instead of letting it crash.
Add support for parsing linear time code from
an audio source using libltc
https://github.com/x42/libltc
The user can now choose between 3 different and independently
running timecode sources. The old override-existing property
has been replaced by timecode-source.
https://bugzilla.gnome.org/show_bug.cgi?id=784295
This element can be configured to add jitter and/or drift to incoming
buffers' PTS, DTS, or both. Amplitude and average of jitter and drift
are configurable.
https://bugzilla.gnome.org/show_bug.cgi?id=787358
avwait can now be configured to stop when a given timecode has been
reached. It will start at the timecode indicated with start-timecode and
end at the timecode indicated with end-timecode. If end-timecode is
NULL (default), the previous functionality is preserved: keep going and
not end.
https://bugzilla.gnome.org/show_bug.cgi?id=789403
* Avoid copying the pending data and instead create a buffer directly from
that data with the appropriate offset.
* Locate the jp2k magic to determine the exact location of the (first) frame
data instead of assuming that the header is of an expected size
https://bugzilla.gnome.org/show_bug.cgi?id=786111
The jp2k specification (ITU-T T.800) specifies that the 'brat' box
has two fields and the second one (AUF2) can be set to 0 for progressive
streams.
The problem is that the mpeg-ts specification (ITU-T H.222.0 06/2012)
says that the AUF2 field is only present if the stream is interlaced
In order to cope with both situation, accept those next 32bit if the
stream is marked as progressive and those bits contain 0
https://bugzilla.gnome.org/show_bug.cgi?id=786111
Crossfading is a bit more complex than just having two pads with the
right keyframes as the blending is not exactly the same.
The difference is in the way we compute the alpha channel, in the case
of crossfading, we have to compute an additive operation between
the destination and the source (factored by the alpha property of both
the input pad alpha property and the crossfading ratio) basically so
that the crossfade result of 2 opaque frames is also fully opaque at any
time in the crossfading process, avoid bleeding through the layer
blending.
Some rationnal can be found in https://phabricator.freedesktop.org/T7773.
https://bugzilla.gnome.org/show_bug.cgi?id=784827
These elements allow splitting a pipeline across several processes,
with communication done by the ipcpipelinesink and ipcpipelinesrc
elements. The main use case is to split a playback pipeline into
a process that runs networking, parser & demuxer and another process
that runs the decoder & sink, for security reasons.
https://bugzilla.gnome.org/show_bug.cgi?id=752214
This allows us to know exactly where in the material track we are, and
how to convert from a PTS for a source track to the actual PTS of the
material track (i.e. by adding the component start position).
https://bugzilla.gnome.org/show_bug.cgi?id=785119
While the size in the packet is only 16 bits, we need to handle bigger
sizes without overflowing. For video streams this can happen, 0 is
written to the stream instead.
This fixes muxing of buffers >= 2**16.
In this case, we assume that the format is jpc, and we infer the color
space from the number of components. This allows the parser to process a
jpc disk file coming from a filesrc element.
https://bugzilla.gnome.org/show_bug.cgi?id=783291
It is only relevant in deciding whether or not send SEGMENT_DONE.
In this case, not detecting EOS leads to a busy loop when encountering
the originally recorded end-of-file of a file that is still growing.
While only filler packets should be allowed, for good measure also skip
any other KLV packets in the range where there could be index table
segments.
This fixes parsing of partitions with multiple index table segments,
which are separated by a filler packet, or other packets.
This is needed to know the PTS, without that we only know the DTS and
using that also for the PTS is wrong unless we have an intra-only codec.
If we can't get the temporal reordering from the index table, don't set
any PTS for non-intra-only codecs and let decoders figure out something.
https://bugzilla.gnome.org/show_bug.cgi?id=784027
When retrieving the `mxfdemux.structure` property, it leads to an
assertion as metadatas need to be resolved for the call to
mxf_metadata_base_to_structure to be valid.
The RSIZ capabilities tag stores the JPEG 2000 profile. In the case of
broadcast profiles, it also stores the broadcast main level, which
specifies the bit rate.
https://bugzilla.gnome.org/show_bug.cgi?id=782337
Also swap the linktype after we detected that we need to do
byteswapping. Fixes a problem with reading pcap files generated
on a machine with different endianness.
When caps changes while streaming, the new caps was getting processed
immediately in videoaggregator, but the next buffer in the queue that
corresponds to this new caps was not necessarily being used immediately,
which resulted sometimes in using an old buffer with new caps. Of course
there used to be a separate buffer_vinfo for mapping the buffer with its
own caps, but in compositor the GstVideoConverter was still using wrong
info and resulted in invalid reads and corrupt output.
This approach here is more safe. We delay using the new caps
until we actually select the next buffer in the queue for use.
This way we also eliminate the need for buffer_vinfo, since the
pad->info is always in sync with the format of the selected buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=780682
When there are more than 64 channels, we don't want to exceed the
bounds of the ordering_map buffer, and in these cases we don't want to
remap at all. Here we avoid doing that.
Based on a patch originally for plugins-good/interleave in
https://bugzilla.gnome.org/show_bug.cgi?id=780331
This duplicated property is no longer needed as there is now API to
allow bindings access GST_TYPE_ARRAY (see gst_util_get/set/object_array).
Additionnally, Python has proper overrides which will make this looks
like Python. A 2x2 matrix would be set this way:
element = matrix = Gst.ValueArray(Gst.ValueArray([1.0, -1.0]),
Gst.ValueArray([1.0, -1.0))
Notice that you need to "cast" each arrays to Gst.ValueArray, otherwise
there is an ambiguity between Gst.ValueArray and Gst.ValueList list type.
Fortunatly, Gst.ValueArray implements the Sequence interface, so it can
be indexed like normal python matrix.
Inserts AU delimeter by default if missing au delimeter from upstream.
This should be done only in case of byte-stream format.
Note that:
We have to compensate for the new bytes added for the AU, otherwise
insertion of PPS/SPS will use wrong offsets and overwrite wrong data.
Also mark the AU delimiter blob const, and use frame->out_buffer for
storing the output to keep baseparse assumptions valid.
Original-Patch-By: Michal Lazo <michal.lazo@mdragon.org>
Helped by Sebastian Dröge <sebastian@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=736213
Those are the rules:
In the SPS:
* if frame_mbs_only_flag=1 => all frame progressive
* if frame_mbs_only_flag=0 => field_pic_flag defines if each frame is
progressive or interlaced, thus the mode is 'mixed' in GStreamer
terms.
https://bugzilla.gnome.org/show_bug.cgi?id=779309
Doing lazy conversion of PCR values doesn't work right
when a PCR discont is encountered. Instead, convert PCR
values to the continuous timestamp domain as soon as we
encounter them and store that instead.
This element transforms a given number of input channels into a given number of
output channels according to a given transformation matrix. The matrix
coefficients must be between -1 and 1. In the auto mode, input/output channels
are automatically negotiated and the transformation matrix is a truncated or
zero-padded identity matrix.
https://bugzilla.gnome.org/show_bug.cgi?id=777376
See https://bugzilla.gnome.org/show_bug.cgi?id=773666
This would ideally be solved in baseparse but that requires further
thought at this point, and in the meantime it would be good to have
rawbaseparse not assert on this but handle it gracefully instead.
DVDs always have subpictures that start on an even Y
coordinate, but gstspu does more generic vobsubs these
days, so handle ones that start on an odd vertical position.
https://bugzilla.gnome.org/show_bug.cgi?id=777400
timecodestamper will post an element message which contains the current
timecode it just stamped. If a timecode was already found and not
replaced, it will still post it in a message.
https://bugzilla.gnome.org/show_bug.cgi?id=777048
... rather than when determining when to end the frame.
The opportunity to do so might not come when forced to drain,
and it seems nicer anyway to do so at parse wrapup time.
This happens if we had no CAPS event yet but e.g. got an EOS event. We
would then try to output a 0-sized buffer, but getting that from the
adapter will give an assertion, return NULL and then crash.
If they were not ported after 4+ years it seems unlikely that anybody is
ever going to need them again. They're still in the GIT history if
needed.
https://bugzilla.gnome.org/show_bug.cgi?id=774530
Compositor does not support it currently and it needs special support
for handling this correctly, and is rather non-trivial to implement for
all formats.
For frame->buffer, baseparse is doing that automatically for us. For
frame->output_buffer it doesn't and assumes that the subclass is already
doing that. Consistency!
This is useful e.g. if audio buffers should be exactly the duration of a
video frame, or if a audio buffers should never be too large because of
latency constraints.
The element is taking a fractional buffer duration, to allow working
with e.g. 1001/30000 as output duration and it accumulates rounding
errors in the buffer durations and compensates for them by making some
buffers one sample larger than the others.
https://bugzilla.gnome.org/show_bug.cgi?id=774689
We will allocate a screen area of width*height*bpp bytes, however this
calculation can easily overflow if too high width or height are given
inside the stream. Nonetheless we would just assume that enough memory
was allocated, try to fill it and overwrite as much memory as wanted.
Also allocate the screen area filled with zeroes to ensure that we start
with full-black and not any random (or not so random) data.
https://scarybeastsecurity.blogspot.gr/2016/11/0day-poc-risky-design-decisions-in.html
Ideally we should just remove this plugin in favour of the one in
gst-libav, which generally seems to be of better code quality.
https://bugzilla.gnome.org/show_bug.cgi?id=774533
Type cast has higher precedence than bitwise shift, so the third
argument will truncate to 8 bits and then shift right by 8 bits
resulting in constant zero.
https://bugzilla.gnome.org/show_bug.cgi?id=774293
Consistently use GST_ROUND_UP_4(width) as stride for
bayer buffers. Bayer data will usually come in widths
that are multiples of 4 anyway, so hopefully this
should not have any adverse impact on anyone in
practice.
Before, bayer2rgb required input buffers to are sized
accordingly, but then didn't actually round up when
calculating row offsets. rgb2bayer didn't use a rounded
stride nor buffer size.
https://bugzilla.gnome.org/show_bug.cgi?id=752014
rawvideoparse wouldn't error out on not-negotiated,
but would just keep on going, because it didn't pass
the flow return value back to the parent class and
thus upstream, so the source wouldnt' stop streaming.
MSVC warns about this because it's a C++ compiler, and this actually
results in useful things such as the incorrect 'gboolean' return value
for functions that return GstFlowReturn, so let's do explicit
conversions to reduce the noise and increase its efficacy.
With MSVC, this gives the following warning:
warning C4305: 'function': truncation from 'double' to 'gfloat'
Apparently, MSVC does not figure out what type to use for constants
based on the assignment. This warning is very spammy, so let's try to
fix it.
In file included from ../subprojects/gst-plugins-base/gst-libs/gst/video/video.h:27:0,
from ../subprojects/gst-plugins-bad/gst/segmentclip/gstvideosegmentclip.c:25:
../subprojects/gst-plugins-base/gst-libs/gst/video/video-format.h:27:39: fatal error: gst/video/video-enumtypes.h: No such file or directory
#include <gst/video/video-enumtypes.h>
^
compilation terminated.
https://ci.gstreamer.net/job/GStreamer-master-meson/269/console
In M2TS mode, we need an extra 4 bytes in the buffer, so need
to ensure the buffer can contain these. The allocation site
does not know the mode, so this is done in all cases.
This was a regression.
We only have a upstream-id via STREAM_START if we were in push-mode.
In pull-mode we need to create one.
Note: It would be good to eventually have that method (copied from
gst_pad_get_stream_id_internal()) public in the future
For each MpegTSBaseStream, we have a GstStream object which
subclasses can extend with information.
For each program a GstStreamCollection is created with all
GstStream from each stream.
When dealing with TIME-based input, the incoming stream could have
potentially changed completely.
In order to check whether it did or not, we need to re-check all sections
(PAT, PMT...). If it didn't, we will keep using the existing streams/pad,
and if it did we will act as if there was a program switch.
Fixes HLS streaming with decodebin3/playbin3
The default value of D-bit is changed to TRUE so discontinuity
is set for initial request and seek request as well.
Only set the e_bit flag for the CUSTOM_DOWNSTREAM event if
a cached buffer exists.
https://bugzilla.gnome.org/show_bug.cgi?id=770221
EAC3 bit streams shall be identified with a stream_type value of 0x87 when
transmitted as PES streams conforming to ATSC-published standards. It is specified
in ATSC Standard A/52.
https://bugzilla.gnome.org/show_bug.cgi?id=770528
The headers passed as parametter are relative to the build dir
basically "../subproject/gst-plugins-bad/gst-libs/gst/mpegts/XXX.h"
but that does not match what is needed at build time when building as
subproject, also we always add current dir as include_dir so we are
safe including directly.
And link mpegtsdemux against the 'math' library as it is needed.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Matej Knopp <matej.knopp@gmail.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
_stdint.h is generated by Autotools and we don't really need it. All
supported platforms now ship with stdint.h. The only stickler was MSVC,
and since Visual Studio 2015 it also ships stdint.h now.
After seeking in aiff files the information about the data end offset is
discarded, leading to audio artifacts with metadata chunks at the end of
a file.
This patch retains the end offset information after a seek event.
https://bugzilla.gnome.org//show_bug.cgi?id=769376
