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
