User often want to set encoder properties on encoding profiles,
this introduces a way to easily 'preset' properties when defining the
profile. This uses GstStructure to define those properties the same
way it is done in `splitmux` for example as it makes simple to handle.
This also defines a more complex structure type where we can map a set
of properties to set depending on the muxer/encoder factory that has
been picked by EncodeBin so it is quite flexible.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1002>
If there are 3 or more known atoms in a row, it's likely that this is
actually MOV/MP4 even if we don't find any other known atoms. If 5 or
more are found then this is most certainly MOV/MP4 and we can return.
Also if a moov and mdat atom is found, this is definitely a MOV/MP4 file
and can be used as such, independent of anything else following the
mdat.
Fixes typefinding of various MOV files that have no `ftyp` atom but
otherwise a valid file structure followed by some garbage.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1013>
These parameters are incorrectly regarded as mutable in G-IR making them
"incompatible" with languages that are explicit about mutability like
Rust. In order to clean up the code and expected API there, update the
signatures here, right at the source (instead of overriding them in
Gir.toml and hoping for the best).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1005>
When filling the checker pattern from multiple threads, y_start
needs to be taken into account to determine the shade of the
current pixel.
Example pipeline:
gst-launch-1.0 videotestsrc ! video/x-raw, width=1920, height=1080, format=I420 ! \
queue ! compositor sink_0::xpos=200 ! video/x-raw, format=I420 ! videoconvert ! \
xvimagesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/988>
The initial byte offset should be calculated from the stride,
not from the dest_add variable
Example pipeline:
gst-launch-1.0 videotestsrc ! video/x-raw, width=1920, height=1080, format=YUY2 ! \
queue ! compositor sink_0::xpos=200 ! video/x-raw, format=YUY2 ! xvimagesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/988>
The correct way to determine the byte offset at a certain yoffset
in a subsampled component is to shift the yoffset by the component's
hsub
This fixes out-of-bounds memory accesses and visible artefacts,
example pipeline with the samples from #802:
gst-launch-1.0 compositor name=vmixer sink_1::xpos=1910 sink_1::ypos=1080 ! \
videoconvert ! videorate ! xvimagesink \
filesrc location=VID_20200723_203606.mp4 ! decodebin name=demux1 ! \
queue ! videoflip method=vertical-flip ! vmixer. \
filesrc location=bridgeoverstubbledwater.mp4 ! decodebin name=demux2 ! \
queue ! vmixer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/988>
This was only taken care of previously if there was a decoder before.
However if previously a decoder was not needed then the ghostpad
would've been linked directly to the slot's srcpad.
Reconfiguring the slot requires this to be undone so that linking can
happen normally.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/985>
Add a way for applications to specify that the underlying file is
growing which implies that the source won't EOS when reaching the end
of the file but instead start monitoring it and start reading it again
whenever a change is detected.
Also add a validate test to check the behavior
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/937>
Instead of going through the list of known muxers go ahead and
instantiate the muxer specified as 'preset name' as this specifies
the exact element factory name to use.
When that property is left to its default, the width and height
property considers frames from input pads with width or height <= 0
should be left unscaled in that dimension.
Setting this property to FALSE changes that behaviour to < 0, as when
animating these properties, 0 should be a valid end value (eg. shrinking
an input stream until it disappears).
The default value of the width and height properties is set to -1, so that
the default behaviour stays consistent whether that new property is set
or not.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/923>
In the case `videoaggregator` is set as allowing format conversions,
and as we convert only on the sinkpads, we should ensure that the
chosen format is usable by the subclass. This in turns implies
that the format is usable on the srcpad.
When doing conversion *any* format can be used on the sinkpads, and this
is the only way that we can avoid race conditions during renegotiations
so we can not change that fact, we just need to ensure that the chosen
intermediary format is usable, which was not actually ensured before
that patch.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/834
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/909>
Increases the throughput of compositing by using more CPU cycles across
multiple threads. Simple cases (the output contains one pixel from at
most one input) can have up to a 70% increase in throughput. Not so
simple cases are limited by the region with the most number of
composite operations.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/755>
The type is called GstVideoTransferFunction so the function names should
match, otherwise gobject-introspection is keeping the functions as
global functions instead of methods on the type.
The same mistake was also made in lots of other APIs over the years, but
here we can at least fix it for 1.18 still.
Thanks to Marijn Suijten for noticing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/807>
When a pad has alpha != 1.0 it means that the resulting frames will
contain alpha and thus can't fully obscure with a lower zorder.
Also simplifies the other checks as blending with an OVER or on a
transparent is not a no-op as previously assumed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/764>
It was not working properly and the implementation of the smartencoder
element was weird. This introduce a number of changes (which are all
in one single commit because they basically all work together and lead
to basically reimplementing the element):
* Make smartencoder a bin so that the reencoding chain of elements are
inside of it instead of not having any parent. Those elements were not
be visible when dumping the pipeline which was very confusing.
* Make encodebin create the right encoder with a capsfilter (and parser)
to properly enforce the format specified by the user, and so that the
encoder properties specified in the encoding profile are respected.
* Use `decodebin` to do the decoding instead of selecting a decoder
ourself and not plug any parser etc...
* Ensure that negotiated format in the sinkpad of smart encoder is fixed
through time when the user requested a non dynamic output
* Add a parser at the beginning of the smart encoder
* Handle errors when reencoding
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/751>
When using tile format, the stride has a different meaning. It used
the MSB and LSB 16bits to encode respectively the width and height in
number of tiles.
This issue was introduce with commit e5b70d384c which was fixing
missing size recalculation when strides and offset is updated.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/753>
Whenever a new collection is calculated, the internal `select_streams_seqnum`
variable is reset. This ensures that we reliably know whether a select-streams
event has been received for that new collection.
Use that to decide whether we should add previously un-selected streams or new
streams in the current selection
Fixes#784
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/733>
For example, BT709, BT601, and BT2020_10 all have theoretically
different transfer functions, but the same function in practice. In
these cases, we should use the fast path for negotiating. Also,
BT2020_12 is essentially the same as the other three, just with one more
decimal point, so it gives the same result for fewer bits. This is now
also aliased to the former three.
Also make videoconvert do passthrough if the caps have equivalent
transfer functions but are otherwise matching.
As of the previous commit, we write the correct transfer function for
BT601, instead of the (functionally identical but different ISO code)
transfer function for BT709. Files created using GStreamer prior to that
commit write the wrong transfer function for BT601 and are, strictly
speaking, 2:4:5:4 instead. However, this commit takes care of
negotiation, so that conversions from/to the same transfer function are
done using the fast path.
Fixes#783
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/724>
It is possible for subtitle files to have a string length less than 30.
WebVTT for example may contain only the 'WEBVTT' string in the file
without any cues.
As an example in hls streams, since WEBVTT files can be segmented
like video/audio, some subtitle segments may only contain just the
header string.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/708>
When linking source pads to decodebin, make sure we use the *specified* new
source pad and not some random one.
This avoids ending up with source pads being unlinked.
Main cause of random timeouts with rtsp change_state_intensive validate tests
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/687>
Otherwise there is a mismatch between the QoS values and what upstream
would expect, leading to too much buffer dropping in video decoders in
case rate < 1.0 or not enough buffer dropping in case rate > 1.0
Adding validate tests with and without decoders.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/679>
We need to take into account the base_ts to compute next_ts and it needs
to be updated on rate change.
This introduces `pending_rate` so that change rate is properly handled
in the streaming thread in a safe way.
Added tests
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/679>
Currently, videoscale just drops all metas that have other tags
besides video. However videoscale wont change the colorspace or
the orientation of the video so metas tagged as such may be
copied safely. Additionaly, given that videoscale will change
the frame size, we invoke the meta transform implementation
to give it the opportunity to scale accordingly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/548>
Especially when changing the sample rate our timestamp tracking will be
completely off, but even otherwise we would usually lose the last few
samples if we don't drain here as the resampler gets reset if anything
but the sample rate changes.
This is usually not a problem as the first buffer after a caps event
usually has the discont flag set, but can cause problems if
- the caps event is followed by a segment event, which then causes
draining according to the new sample rate
- the caps were changed because of rengotiation due to a reconfigure
event and there is not discontinuity from upstream
In both cases we would output buffers with completely wrong timestamps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/670>
Stop comparing all timestamps from buffers that are before the segment
with the segment.stop and compare with the actual end times.
Comparing to segment.stop for all the buffers that where before
the segment.stop was incorrect and leading to consuming wrong buffers
and not respecting segment.stop, this is now properly tested.
Expectations for `reverse.10_to_1fps.validatetest` have been fixed to
take that into account and comparing the checksums of the sinkpad and
srcpad expectations makes pretty clear how wrong that was.
(we can see in the expectations that videotestsrc outputs an extra
buffer with pts == segment.stop and this one is now properly dropped
by videorate as bec7f4ad5e aimed at
doing)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/668>
In reverse playback we were not taking into account the current buffer
samples to check if we had reached EOS which was leading to a buffer
with PTS = CLOCK_TIME_NONE containing too many frames followed by a
useless buffer with pts=0 duration=0, and a g_critical issue in
gst_object_sync_values.
Also add a validate based test case.
Without that patch this is how the expectation fails:
``` diff
--- log-asink-sink-expected 2020-05-22 23:22:42.654384579 -0400
+++ log-asink-sink-actual 2020-05-22 23:29:35.671586380 -0400
@@ -27,5 +27,6 @@
buffer: pts=0:00:00.058820861, due=0:00:00.023219955, flags=discont
buffer: pts=0:00:00.035600907, due=0:00:00.023219954, flags=discont
buffer: pts=0:00:00.012380952, due=0:00:00.023219955, flags=discont
-buffer: pts=0:00:00.000000000, due=0:00:00.012380952, flags=discont
+buffer: due=0:00:00.012380953, flags=discont
+buffer: pts=0:00:00.000000000, flags=discont
event eos: (no structure)
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/667>
And fix reverse playback buffer duration computation as in reverse
playback, buffer duration is prev_buffer.pts - buffer.pts not pts -
next_pts (buffers are displayed from buffer.pts + buffer.duration for
a duration of buffers.duration).
This is now tested with the `validate.test.clock_sync.videorate.*`
tests in the default integration testsuite where we check the exact
data flow and the synchronization on the clock behaviour with a
TestClock.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/646>
In reverse playback, buffers have to be displayed at buffer.stop running
time, meaning:
buffer.pts + buffer.duration = prev_buffer.pts
=>
buffer.duration = prev_buffer.pts - buffer.pts
We were setting buffer.duration = next_buffer.pts - buffer.pts which
is not correct.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/646>
Include the Program Stream Map packet type 0xBC in the
set of packets we treat as PES. This fixes typefinding
on MPEG-PS streams with PSM, where the PSM would previously
be considered a loss-of-sync and cause the typefind
to require more data.
The string "\"OTIO_SCHEMA\":" is 14 characters and not 15. Checking for
15 characters would also check for the final '\0', which does not exist
in any otio file as the string is the key of a JSON map.
memcmp() returns 0 (aka FALSE) on match and a difference otherwise.
Previously the typefinder was matching on anything but otio files that
happened to have some curly braces in the beginning of the file.
Fixes a false positive with a MOV file.
Previously configured bufferpool can be expired/inactivate by the
updated caps. Therefore new reconfigure event should be signalled in order to
do allocation query dancing between upstream and downstream again.
Fixes: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/730
