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
Move the pixel-aspect-ratio calculations higher up in caps
determination, so the results are available for a call to
gst_video_multiview_guess_half_aspect() when stereoscopic video
is detected.
Use QOS messages to update rendered and dropped frame stats. This is
the only accurate method. The old method didn't take max-lateness and
latency into account.
After few iteration, this variable became the same as dts. It's not
the min as the name says, but the dts of the current buffer. Simply
remove and place with dts. Also move the debug trace to actually
print the signed version of the running-time dts.
after e000a6f0a4, there is build error in bad plugins
this happens because, GST_CLOCK_STIME_IS_VALID () is being checked for pad_data
but it expects a GstClockTime parameter. Changing the check to 'dts'
https://bugzilla.gnome.org/show_bug.cgi?id=750961
The segment should start at first PTS, and the vairable name lower_pts
state so correctly. Though we where using the first DTS instead. This
could lead to small desynchronization of video stream.
https://bugzilla.gnome.org/show_bug.cgi?id=740575
Use the saved DTS, make it signed and pass that to the stream muxer. This
preserves the running time sign. All usage of -1 as invalid TS are now
replaced with G_MININT64. Negative values will be seen as wrap-around
point, but the delta between PTS and DTS will remain correct. Demuxers
don't care about absolute values, they only cares about deltas.
https://bugzilla.gnome.org/show_bug.cgi?id=740575
There was code to detect backward dts, but the marker min_dts
was never set. Setting it enable this feature that prevents
potential integer overflow when generating TS.
https://bugzilla.gnome.org/show_bug.cgi?id=740575
Wait until at least one keyframe has been parsed before
deciding to switch to passthrough mode, in case the
stream contains SEI messages that supplement the output
caps - for example by providing stereoscopic information
We were off by one byte in the matching
It should be (using 24 bit matching):
* startcode : 0000 0000 0000 0000 1000 00xx
* mask (bin) : 1111 1111 1111 1111 1111 1100
* mask (hex) : f f f f f c
* match : 0 0 0 0 8 0
https://bugzilla.gnome.org/show_bug.cgi?id=750685
In case of the videomark being partially or fully outside,
an error was bein thrown saying, mark width is more than video width.
And when the width, offset properties are set to maximum it resulted in crash.
Instead of throwing error, added logic to detect the mark
in case of partial visibility or dont show the mark when it is outside.
https://bugzilla.gnome.org/show_bug.cgi?id=743908
In case of the videomark being partially or fully outside, an error was being
thrown saying the mark width is more than video width. And when the width,
offset properties are set to maximum it resulted in crash. Instead of throwing
an error, add logic to detect the mark in case of partial visibility or don't
show the mark when it is outside.
https://bugzilla.gnome.org/show_bug.cgi?id=743908
