When seeking in pull mode without an index (because there is no index
or the file is still being written to) we bisect to find the right
cluster to jump to. However, it's possible the cluster we found doesn't
start with a keyframe, which leads to decoding errors, so if we know
that the found cluster starts with a delta frame try to scan back to
previous clusters until we find one that starts with a keyframe or
we are back at the beginning. Theoretically it's possible that all
clusters but the first one do not start with a keyframe and the
keyframes are in the middle of clusters, but this is extremely
unusual, so we will cover this case with a basic sanity check.
This problem is especially problematic with content recorded with
dynamic GOP and FPS, where long GOP lengths and low FPS may cause a
large set of clusters to lack key frames. Playback would then be
started on a non-keyframe cluster, and the large number of such frames
would make the content impossible to decode fo a long stretch of time.
Based on patch by: Mats Lindestam <matslm@axis.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790696
This is useful for reverse playback/trickmodes
without an index, and will also be useful in the
seek handler if we need to scan back to find a cluster
that starts with a keyframe.
https://bugzilla.gnome.org/show_bug.cgi?id=790696
This is an enum not a boolean, and a value of 2 signals
that the video is progressive, but we would mistakenly set
interlace-mode=mixed on the output caps.
https://bugzilla.gnome.org/show_bug.cgi?id=787206
On Linux, the kernel returns twice the size as it will allocate extra
space for accouting. We devides this value by two in order to ensure
that get/set value now match. This fixes the set buffer size validation
and allow having a nice warning when the size if surpassed and the
process does not have CAP_NET_ADMIN capabilities.
https://bugzilla.gnome.org/show_bug.cgi?id=727067
The udp buffer size is limited to a maximum of around 100K.
Some apps need to set the force bufsize for their own operation.
Use the SO_RCVBUFFORCE option in order to override the rmem_max limit
of linux kernel. Require user to have the CAP_NET_ADMIN privilege to
work.
Original patch from Kyungnam Bae <kyungnam.bae@lge.com>
https://bugzilla.gnome.org/show_bug.cgi?id=727067
rtph264pay and rtph265pay skip updating the parameter set timestamp if
the units they see contain no new configuration. This can result in
them injecting duplicate parameters.
https://bugzilla.gnome.org/show_bug.cgi?id=796748
The stream context was holding a reference to the
internal queue and pads, with pad probes that were
in turn holding references to the stream context.
This lead to a leak if the request pads weren't explicitly
released.
https://bugzilla.gnome.org/show_bug.cgi?id=796893
All these were copy pasted and would lead to assertion when chained with
rtpmux. This commit rewrite the negotiation with downstream. This also
drop the fallback to ancient names if the pad is unlinked. This was
completly arbitrary decision that made no sense.
https://bugzilla.gnome.org/show_bug.cgi?id=796809
Pass through closed caption data when deinterlacing. When two
deinterlaced frames are created for the same interlaced frame (e.g.
fields=all), the second of the two frames will have no closed caption
data.
Also fixed memory leaks related to timecode meta pass-through.
https://bugzilla.gnome.org/show_bug.cgi?id=796876
This causes rtspsrc to send a teardown and wait on
PAUSED->READY transition, with a configurable delay.
Otherwise, typically teardown never gets sent in
playbin / uridecodebin where the transition back to NULL
happens too quickly.
The timeout is set to 100ms default.
https://bugzilla.gnome.org/show_bug.cgi?id=751994
Just remove the code. It's not doing anything useful anyways. The modified
caps are the result of a caps query, so either not used afterwards of a
reference to some internal caps of another element that should not be
modified.
https://bugzilla.gnome.org/show_bug.cgi?id=796837
When it is trivial to pass-through a timecode, by only removing the
"interlaced" flag, do pass-through. Otherwise, double the fps_n and
adjust the "frames" field.
https://bugzilla.gnome.org/show_bug.cgi?id=796818
When handling input with timestamps that repeat, sometimes
splitmuxsink would get confused and ignore a keyframe.
The logic in question is a holdover from before the cmd queue
moved the file cutting to the multiqueue output side and made
it deterministic, so it's no longer needed on the input
here.
https://bugzilla.gnome.org/show_bug.cgi?id=796773
This reverts commit 3ac5430311.
There's no need to make a freshly created event writable,
and the other half of this patch was already fixed
and pushed in f2f15a1
Always wait with starting the RTCP thread until either a RTP or RTCP
packet is sent or received. Special handling is needed to make sure the
RTCP thread is started when requesting an early RTCP packet.
We want to wait with starting the RTCP thread until it's needed in order
to not send RTCP packets for an inactive source.
https://bugzilla.gnome.org/show_bug.cgi?id=795139
* When receiving a segment in TIME, use that seqnum
* Only reset the stored sequence number when doing HARD reset
(and not when we get a FLUSH event from upstream)
This patch aims at fixing the recent regressions in the adaptive test
suite.
All segment pushing in push mode is now done with
gst_qtdemux_check_send_pending_segment(), which is idempotent and
handles both edit lists cases and cases where the upstream TIME segments
have to be sent directly.
Fragmented files that start with a non-zero tfdt are also taken into
account, but their handling has been vastly simplified: now they are
handled as implicit default seeks so there is no need to extend the
GstSegment formulas as was being done before.
qtdemux->segment.duration is no longer modified when
upstream_format_is_time, respecting in this way the durations provided
by dashdemux and fixing bugs in reverse playback tests where mangled
durations appeared in the emitted segments.
https://bugzilla.gnome.org/show_bug.cgi?id=752603
Upstream driving elements such as dashdemux often do reverse playback by
feeding qtdemux with the fragments containing the requested playback
range in reverse order.
But the requested playback range stop may be somewhere in the
middle of a fragment. In that case, a naive pts >= segment.stop
condition may declare end of segment prematurely when demuxing this
first fragment.
This used not to happen because there were places in moov parsing where
segment.stop was overwritten to GST_CLOCK_TIME_NONE even if
upstream_format_is_time -- resulting in this case in a segment with rate
< 0 and stop == -1 and hence not triggering the EOS check, but that was
likely an accident.
This patch modifies the EOS check to take this case into account, not
sending EOS when upstream_format_is_time if rate < 0.
This fixes adaptive.dash.playback.seek_end_live.DASHIF_livestream_testpic_2s
https://bugzilla.gnome.org/show_bug.cgi?id=752603
