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
When the pool is started, we allocate and release buffer, expecting
the pool release-buffer handler to queue them. Though, as we rely
on release function, there is no direct way to detect that this
process didn't work.
To check this, validate that the number of queued buffer is the same
as the number of allocated buffers. This allow returning an error
when buffer importation was refused by the driver.
https://bugzilla.gnome.org/show_bug.cgi?id=583890
This will avoid sending EOS on v4l2src when a driver sends an empty
buffers. This case would be a bug in the driver, but yet the camera
should keep running.
This also removes the check for corrupted buffers, as this check is
already done later.
https://bugzilla.gnome.org/show_bug.cgi?id=794842
We were calling gst_v4l2_is_buffer_valid() before and inside
gst_v4l2_buffer_pool_qbuf() as we needed to access the group. The second
check failed since the writability of the buffer get inherited from the
GstMemory, which lead to pipeline failure. As we cannot avoid the extra
ref, it would be racy otherwise, just pass the group to _dbuf() so it
does not have to call gst_v4l2_is_buffer_valid() again.
https://bugzilla.gnome.org/show_bug.cgi?id=796692
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
Some camera firmware crash is TRY_FMT is called during streaming. As a
side effect. This try and detect that the same format as currently
running is about to be tried, and skip renegotiation.
https://bugzilla.gnome.org/show_bug.cgi?id=796789
In some cases, set_format() may get called twice before the output
format is set. Running an allocation query in this case is both not
needed and will cause assertion due tot he NULL caps.
* 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)
The first converter to be found will now gain the name v4l2convert.
Other converters will be named after the m2m dev node end point they are
attached to.
https://bugzilla.gnome.org/show_bug.cgi?id=784958
When the decoder get linked further, it will receive a renegotiation
event from downstream. This case is not supported and should be ignored.
This fixes issues when this encoder is used inside an GstRtspServer
pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=796525
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
This fixes patch dd1c5aed65 which
pretended to always set colorimetry but the patch was incomplete.
This is again best effort considering the spec says that for CAPTURE
you may only read this value.
gst_v4l2_buffer_pool_flush() executes streamoff for the output, but
streamoff->streamon for the capture of the decoder.
gst_v4l2_buffer_pool_streamon() on capture assumes that is able to
resurrect the buffers from the pool, but acquiring buffers fails if the
buffer pool is still flushing.
The decoder needs to stop flushing the pools before calling
gst_v4l2_buffer_pool_flush() to restart the v4l2 device. Otherwise
starting the decoding thread might fail, because there are no buffers in
the capture pool.
This fixes a regression that was introduced in 97985a335c
("v4l2videodec: Add dynamic resolution change support").
https://bugzilla.gnome.org/show_bug.cgi?id=796681
The S_CROP call doesn't work on mem2mem output queues. Use the
S_SELECTION call to set the crop rectangle and only fall back to
S_CROP for ancient kernels.
This will allow v4l2videoenc to set the coded size on the output
queue via S_FMT and then set the visible size via the crop rectangle,
as required by the V4L2 codec API.
https://bugzilla.gnome.org/show_bug.cgi?id=796672
Some drivers need output buffers set before capture buffers.
CODA cannot set output format if capture is streaming.
Exynos MFC fails on output STREAMON if capture is already streaming.
This patch delays capture activation until output is configured and
streaming
https://bugzilla.gnome.org/show_bug.cgi?id=796693
Drop truncated frames regardless if they have the ERROR flag or not.
Truncated frame causes video frame map failure in many elements
including cluttersink, glupload etc.
In this patch we use a non-blocking poll in order to return all input
buffers (buffers from v4l2-output queue). This prevent holding too long
on upstreaming buffer in importing.
https://bugzilla.gnome.org/show_bug.cgi?id=794904
Sample table based segment event (genereted by qtdemux) could break
presentation timeline. For example, qtdemux should not modify upstream
time format segment (e.g., adaptivedemux use case)
https://bugzilla.gnome.org/show_bug.cgi?id=796480
