Scene detection determines, how many scenes have changed in a video.
It compared the previous frame with present frame to find out the score and a
threshold is calculated for the same.
I have added an intermediate condition which helps in improving the positive
detections.
https://bugzilla.gnome.org/show_bug.cgi?id=735094
We were assuming that NULL pool meant that downstream didn't reply.
Update the pool index 0 instead of adding at the end. Otherwise we ended
up letting basesrc decide, which would pick the blocksize as a size
(4096) instead of the image size.
https://bugzilla.gnome.org/show_bug.cgi?id=795327
This server uses an unknown 003.889 protocol version. This patch fixes
the version validation in order to simply fallback to 3.3 as suggested
by the spec.
We would mark all streams with FLAG_UNSELECT as we would check
the pointer for non-NULLness not the dereferenced stream number
(and the pointer is always non-NULL). The intention here was
presumably to mark the first stream of each type as SELECT and
the others as UNSELECT by default.
CID 1434970.
This is a simple Bin that will expose audiotestsrc or videotestsrc
based on what is asked by the user either through the GstURIHandler
API or through the "stream-types" property.
This element also provides GstStream and GstStreamCollection
so it is nicely usable from playbin3.
https://bugzilla.gnome.org/show_bug.cgi?id=795366
pcapparse cannot parse fragmented IP packets correctly, in particular it
will get confused when trying to parsing fragments as standalone frames
in two ways:
1. the first fragment will have the packet length greater than the
frame size and will always be discarded;
2. fragments with non-zero offsets will be interpreted as full packets
and the first part of their raw payload data will be parsed as the
transport protocol header, resulting in bogus values for addresses
and ports, thus evading the properties filtering on those values.
This can make it difficult for users to see why the data does not get
downstream.
So be more explicit and just bail out when fragmented packets are
encountered.
https://bugzilla.gnome.org/show_bug.cgi?id=795284
If the 'enable-last-sample' property is enabled, fakevideosink will keep
a reference on last rendered buffer which may lead to buffer starvation
in the pipeline.
Request one extra buffer in this case so we always have a buffer flying
in the pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=795109
When starting up we need to initialise things *before*
streaming starts, so before we chain up to the parent
class in the state change function. And when we shut
down the element, we need to reset things after streaming
has stopped, so after we chain up to the parent class
in the state change function.
Possibly related to memory leak in:
https://bugzilla.gnome.org/show_bug.cgi?id=794353
We used to have the same enum to represent H265 profiles and idc values.
Those are no longer the same with extension profiles defined from
version 2 of the spec.
Split those enums so the semantic of each is clearer and we'll be able
to add extension profiles to GstH265Profile.
Also add gst_h265_profile_tier_level_get_profile() to retrieve the
GstH265Profile from the GstH265ProfileTierLevel. It will be used to
implement the detection of extension profiles.
https://bugzilla.gnome.org/show_bug.cgi?id=793876
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
