An IDX file or codec_data normally contains the original frame size of
the video. Allow upstream to provide this information by sending a
custom event, which will allow scaling the overlay correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=663750
Instead of only supporting writing SPU data directly to YUV frames,
render the SPU data to an intermediate AYUV overlay buffer. The overlay
data is then attached to the video frame if downstream supports overlay
composition, otherwise the AYUV overlay is blended to the video frame.
For the PGS format, the overlay buffer size is set to the size of the
Composition Window, and its position in the overlay composition is set
to the window position. The objects to render are now cropped when the
cropping flag is set.
For the Vobsub format, the overlay buffer size is set to the size of the
Display Area.
Once rendered, the overlay composition rectangle is now moved and scaled
to fit the video output size, to avoid clipping.
https://bugzilla.gnome.org/show_bug.cgi?id=663750
We might've queued up a GAP buffer that is only partially inside the current
output buffer (i.e. we received it too late!). In that case we should only
skip the part of the GAP buffer that is inside the current output buffer, not
also the remaining part. Otherwise we forward this pad too far into the future
and break synchronization.
Derive from GstVideoSink so that preroll frames will automatically
get rendered too, unless the show-preroll-frame property is set to
FALSE. Fixes intervideosrc only picking up frames if intervideosink
is in PLAYING state.
https://bugzilla.gnome.org/show_bug.cgi?id=755049
Fix the negotiation of GstVideoOverlayComposition by checking
intersection with the peer caps, rather than just accept-caps,
which might only check the pad template.
https://bugzilla.gnome.org/show_bug.cgi?id=755113
We have to queue buffers based on their running time, not based on
the segment position.
Also return running time from GstAggregator::get_next_time() instead of
a segment position, as required by the API.
Also only update the segment position after we pushed a buffer, otherwise
we're going to push down a segment event with the next position already.
https://bugzilla.gnome.org/show_bug.cgi?id=753196
x/y/w/h are signed integers. As can be seen in GstCompositorPad.
The prototype for clamp_rectangle was wrong. This commit reverts the change
and fixes the prototype.
This reverts commit bca444ea4a.
CLAMP checks both if value is '< 0' and '> max'. Value will never be a negative
number since it is an unsigned integer. Removing that check and only checking if
it is bigger than max by using MIN().
CID 1320707
As it's recursive, gst_pad_get_allowed_caps() may also return
empty for anything incompatible downstream. EMPTY is not valid caps
value for gst_caps_fixate(). This lead to assertion and then crash.
Ideally, the negotiate function should be re-factored to have a return
value, and we could make the negotiation fails earlier.
https://bugzilla.gnome.org/show_bug.cgi?id=754122
The obscured check in compositor was using the dimensions of the pad to clamp
the h/w of the pad instead of the output resolution, and was doing an incorrect
calculation to do so. Fix that by simplifying the whole calculation by using
corner coordinates. Also add a test for this bug which fell through the cracks,
and just skip all the obscured tests if the pad's alpha is 0.0.
https://bugzilla.gnome.org/show_bug.cgi?id=754107
The tsdemux latency should always be added to the minimum
latency (which is always a valid clock time value). The
"cleanup" in commit a1f709c2 made it so that it would not
be added if upstream reported 0 as minimum latency (as
e.g. udpsrc would). This broke playback of live mpeg-ts
streaming in some cases, leading to playback stutter due
to a too-small configured latency for the pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=751508
In gst_live_adder_chain() function, calls to gst_buffer_copy_region() can lead
to assertion as 'offset + size <= bufsize' is not respected.
Indeed 'offset' and 'size' parameters are calculated through calling gst_live_adder_length_from_duration(),
and thus gst_util_uint64_scale_int_round().
Depending on the nearest integers, rounded values 'offset' and 'size' can then trigger the assertion.
This case mainly occurs when 'skip' value is > 0 in chain function process.
https://bugzilla.gnome.org/show_bug.cgi?id=753759
It is faster than doing a query that propagates downstream and
should be enough
Elements: faac, gsmenc, opusenc, sbcenc, voamrwbenc, adpcmenc, sirenenc
The payloader didn't copy anything so far, the depayloader copied every
possible meta. Let's make it consistent and just copy all metas without
tags or with only the video tag.
https://bugzilla.gnome.org/show_bug.cgi?id=751774
A race condition in the state change function may cause buffers to be
unreffed while they are still used by the streaming thread in
gst_rtp_h265_pay_send_vps_sps_pps() resulting in a crash. Chain up to the
parent class first in the state change function to make sure streaming
has stopped and only then free those buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=741381
The SPS struct might be filled out by a call to
gst_h264_parser_parse_subset_sps, which fills out
dynamically allocated data and requires a call
to gst_h264_sps_clear() to free it. Also make sure
to clear out any allocated SPS data when returning
an error.
https://bugzilla.gnome.org/show_bug.cgi?id=753306
The payloader didn't copy anything so far, the depayloader copied every
possible meta. Let's make it consistent and just copy all metas without
tags or with only the video tag.
https://bugzilla.gnome.org/show_bug.cgi?id=751774
When playing mts files with embedded subtitles, the buffer is mapped,
but not unmapped at the end resulting in a memory leak.
Also unref event in handle_dvd_event as it takes ownership of the event.
https://bugzilla.gnome.org/show_bug.cgi?id=753539
When playing mts files with embedded subtitles, there are few event leaks.
Events are supposed to be transfer full. So if not forwarding the event,
they need to be freed.
https://bugzilla.gnome.org/show_bug.cgi?id=753539
h264parse and gstrtph264depay do the same, let's keep the behaviour
consistent. As we now include the codec_data inside the stream, this causes
less caps renegotiation.
https://bugzilla.gnome.org/show_bug.cgi?id=753228
rtph264depay does the same and this fixes decoding of some streams with 32
SPS (or 256 PPS). It is allowed to have SPS ID 0 to 31 (or PPS ID 0 to 255),
but the field in the codec_data for the number of SPS or PPS is only 5
(or 8) bit. As such, 32 SPS (or 256 PPS) are interpreted as 0 everywhere.
This looks like a mistake in the part of the spect about the codec_data.
This causes an assertion and would lead to getting a NULL instead
of a buffer. Without proper checking this would easily lead to a
segfault.
Related to rpth264depay: https://bugzilla.gnome.org/show_bug.cgi?id=737199
String parameters are expected to be passed as (f0r_param_string *),
which actually map to char**. In the filters this is evaluated as
(*(char**)param) which currently lead to crash when passing char*.
Remove the special case for string, all types, including char* as
passed as a reference.
https://phabricator.freedesktop.org/T83
Check if downstream is seekable via a SEEKING query and output a
BYTE segment if we want to seek back to fix up the headers later,
but if we're streaming send a TIME segment instead (which goes
down better with e.g. asfmux ! rtpasfpay).
https://bugzilla.gnome.org/show_bug.cgi?id=719553
Some video bitstreams report a too restrictive set of profiles. If a video
decoder was to strictly follow the indicated profile, it wouldn't support that
stream, whereas it could in theory and in practice. So we should relax the
profile restriction for allowing the decoder to get connected with parser.
https://bugzilla.gnome.org/show_bug.cgi?id=747613
In the case where you have a source giving the GstAggregator smaller
buffers than it uses, when it reaches a timeout, it will consume the
first buffer, then try to read another buffer for the pad. If the
previous element is not fast enough, it may get the next buffer even
though it may be queued just before. To prevent that race, the easiest
solution is to move the queue inside the GstAggregatorPad itself. It
also means that there is no need for strange code cause by increasing
the min latency without increasing the max latency proportionally.
This also means queuing the synchronized events and possibly acting
on them on the src task.
https://bugzilla.gnome.org/show_bug.cgi?id=745768
VPS is not mandatory, and need not check for its presence before setting
the caps. Because of the check, in streams which don't have VPS,
sticky event mishandling happens.
https://bugzilla.gnome.org/show_bug.cgi?id=752807
In media to caps function, reserved_keys array is being used for variable i,
leading to GLib-CRITICAL **: g_ascii_strcasecmp: assertion 's1 != NULL' failed
changed it to variable j
https://bugzilla.gnome.org/show_bug.cgi?id=753009
Skip keys from the fmtp, which we already use ourselves for the
caps. Some software is adding random things like clock-rate into
the fmtp, and we would otherwise here set a string-typed clock-rate
in the caps... and thus fail to create valid RTP caps
https://bugzilla.gnome.org/show_bug.cgi?id=753009
The PID on a pad shouldn't change on a state change, only
if the pad is freed and a new one created. Clearing the PID
prevented mpegtsmux from being reused, because all packets
would end up muxed in PID 0
https://bugzilla.gnome.org/show_bug.cgi?id=752999
Accumulate streamheader packets in reverse into the
GList for efficiency, and reverse the list once when
processing.
Improves muxing speed when there are a lot of
streamheaders.
Don't throw away AU delimiter(s) that precede the SPS/PPS. Should
fix MPEG-TS playback on iOS/Quicktime when muxing streams that
already have AU delimiters.
See https://bugzilla.gnome.org/show_bug.cgi?id=736213 for getting
h264parse to insert AU delimiters when they don't already
exist.
We need to sync the pad values before taking the aggregator and pad locks
otherwise the element will just deadlock if there's any property changes
scheduled using GstController since that involves taking the aggregator and pad
locks.
Also add a test for this.
https://bugzilla.gnome.org/show_bug.cgi?id=749574
ret is declared just to initialize to TRUE and overwrite with the value of
vret. We can return the value of vret directly. vret is TRUE unless the
forward_event_func sets it to FALSE.
We only want to do a hard reset of the observations if we're working
with TIME segments in push mode. For BYTE segment we want to keep
the observations (in order to do seeks in push-mode).
When in push mode, we want to discard all previous observations from the
mpegtspacketizer when we get a DISCONT buffer.
This avoids trying to calculate bogus timestamps (estimating them using old
PCR observations).
We only do a hard reset in push-mode. In pull-mode we still need the observations
(in order to seek properly)
This is not public API, use g_assert() instead of
g_return_if_fail(), so that it's compiled out in
releases. It's only called from our code, with &foo.
Introduced by c4c9fe60b pcapparse: Take buffer directly from the adapter
Using gst_adapter_take_buffer_fast() can lead to buffers that are
made up of multiple memories with the first memory smaller than the
RTP header size, which violates assumptions GstRtpBaseDepayloader
makes, namely that the complete RTP header will be in the first
memory. This leads to such packets being dropped when feeding
them from pcapparse to RTP depayloaders. Use take_buffer() so
we get buffers with a single memory.
Introduced by c4c9fe60b pcapparse: Take buffer directly from the adapter
Flush any trailing bytes after the payload from the adapter as well,
otherwise we'll read a bogus packet size from the adapter next and
then everything goes downhill from there.
https://bugzilla.gnome.org/show_bug.cgi?id=751879
Can be used to fix misbehaving sinks. It will pass through all buffers
until it encounters GST_FLOW_ERROR or GST_FLOW_NOT_NEGOTIATED (configurable).
At that point it will unref the buffers and return GST_FLOW_NOT_LINKED
(configurable) - until the next READY_TO_PAUSED or FLUSH_STOP.
https://bugzilla.gnome.org/show_bug.cgi?id=750098
