vps/sps/pps in codec_data shouldn't be considered as inband data.
Otherwise, h26{4,5}parse never insert them to nal when transform
(packetized to byte-stream) use case
Similar change as the on I did in h264parse. We want to process SEI
recovery point as keyframe so muxers will mark them as seek points and
decoders will be able to start decoding from them rather than waiting
for an IDR.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/790
The spec states that "recovery point SEI message assists a decoder in
determining when the decoding process will produce acceptable
pictures for display after the decoder initiates random access or after the
encoder indicates a broken link in the coded video sequence."
Mark those as keyframes so muxers will mark them as seek points and
decoders will be able to start decoding from them rather than waiting
for an IDR.
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/790
This removes the crossfade-ratio property and replaces it with an
operator property. Currently this implements the following operators:
- SOURCE: Copy over the source and don't look at the destination
- OVER: Default blending of the source over the destination
- ADD: Like OVER but simply adding the alpha instead
See the example for how to implement crossfading with this.
https://bugzilla.gnome.org/show_bug.cgi?id=797169
If the first audio buffer to be dropped started right between two video
buffers (after the end of the first but before the start of the second,
as is often the case with N/1001 video frame rates), we would miss
sending the dropping=true message.
https://bugzilla.gnome.org/show_bug.cgi?id=797248
tsdemux expects a custom descriptor (GST_MTS_DESC_AC3_AUDIO_STREAM)
to detect a stream as AC3 and not EAC3.
Note that tsdemux expects this descriptor because mpegtsmux writes
a stream with a HDMV registration descriptor.
Fixes:
gst-launch-1.0 -v audiotestsrc ! avenc_ac3 ! ac3parse ! mpegtsmux ! \
tsdemux ! ac3parse ! avdec_ac3 ! audioconvert ! autoaudiosink
https://bugzilla.gnome.org/show_bug.cgi?id=797220
Previously it was dispatched before the last video buffer, and audio
buffers would follow afterwards. It's misleading to send the
dropping=true message before both streams have really stopped, it can
lead to races when someone is e.g. waiting for that message to send EOS.
Also added some debug output.
https://bugzilla.gnome.org/show_bug.cgi?id=797145
Direct applying the commit 7bb6443. This could fix also unexpected
nal dropping when nonzero "config-interval" is set.
(e.g., gst-launch-1.0 videotestsrc ! x265enc key-int-max=30 !
h265parse config-interval=30 ! avdec_h265 ! videoconvert ! autovideosink)
Similar to the h264parse, have_{vps,sps,pps} variables will be used
for deciding on when to submit updated caps or not, and rather mean
"have new SPS/PPS to be submitted?"
See also https://bugzilla.gnome.org/show_bug.cgi?id=732203https://bugzilla.gnome.org/show_bug.cgi?id=754124
If we drain after a discont, the discont time given by the stream
synchronizer is already the time after the discontinuity. But we need to
drain all pending data based on the previous discont time instead.
The case is properly handled a few lines below by dropping the buffer.
We shouldn't perpetually block the audio chain function until the
target-timecode is reached.
https://bugzilla.gnome.org/show_bug.cgi?id=796906
This change allow setting timestamp on streams that would otherwise have
no timestamp. This is useful to make a video from bunch of JPEG files. An
example of such pipeline would be:
gst-launch-1.0 multifilesrc location=%05d.jpeg caps=image/jpeg,framerate=30/1 \
! jpegparse ! fakesink silent=0 -v
It works like a valve in front of the actual avwait. When recording ==
TRUE, other rules are then examined. When recording == FALSE, nothing is
passing through.
https://bugzilla.gnome.org/show_bug.cgi?id=796836
255 will easily become 0 in the blending function as they expect
the maximum value to be 255.
Can be reproduce with
gst-launch-1.0 videotestsrc pattern=ball ! c.sink_0 \
videotestsrc pattern=snow ! c.sink_1 \
compositor name=c \
sink_0::zorder=0 sink_1::zorder=1 sink_0::crossfade-ratio=0.5 \
background=black ! \
videoconvert ! xvimagesink
crossfade-ratio +/- 0.001 makes it work correctly and the same happens
at e.g. 0.25, 0.75, N*0.0625
https://bugzilla.gnome.org/show_bug.cgi?id=796846
Adds AV01 FOURCC to the list of allowed media files, in order to allow
parsing the IVF Container holding AV1 content.
At a later point dynamic resolution change can be supported - therefore
the sequence header OBU and frame header OBU of AV1 file must be parsed,
which can be done in future with the help of gst-lib gstav1parse.
https://bugzilla.gnome.org/show_bug.cgi?id=796677
This moves all the conversion related code to a single place, allows
less code-duplication inside compositor and makes the glmixer code less
awkward. It's also the same pattern as used by GstAudioAggregator.
The aggregated_frame is now called prepared_frame and passed to the
prepare_frame and cleanup_frame virtual methods directly. For the
currently queued buffer there is a method on the video aggregator pad
now.
Unless we only have sparse streams. In this case we will consider them.
It fixes a bug happening when first observed timestamp comes from a
sparse stream and other streams don't have a valid timestamp, yet. Thus
leading the timestamp from sparse stream to be the start of the
following segment. In this case, if the timestamp is really bigger than
non-sparse stream (audio/video), it will lead the pipeline to clip
samples from the non-parse stream.
https://bugzilla.gnome.org/show_bug.cgi?id=744469
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
* 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.
