We shouldn't go through segment activation as we will only have a limited
understanding of how the whole stream timeline looks like from the moof. We
only know about the current fragment, while upstream knows about the whole
stream.
This fixes seeking in DASH streams, both for seeks after the current moof and
for seeks into the current moof. The former would fail because the moof ends
and we can't activate any segment, the latter would cause a segment that stops
at the moof end, and no further fragments would be played because we end up
being EOS.
https://bugzilla.gnome.org/show_bug.cgi?id=767071
To change pixel aspect ratio from DAR to PAR, the necessary scaling factor
is DAR/PAR, not DAR*PAR.
For good measure, add debug output similar to the fixed-width and
fixed-height cases.
https://bugzilla.gnome.org/show_bug.cgi?id=766711
Instead of relying on the default colorimetry chosen by
gst_video_info_set_format(), set info.colorimetry from the
values returned by G_FMT. This allows decoders to propagate
their input colorimetry downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=766383
Move the extraction of colorimetry parameters from struct v4l2_format and the
setting of the identity matrix for RGB formats into the function to avoid code
duplication.
https://bugzilla.gnome.org/show_bug.cgi?id=766383
gst_v4l2_probe_caps() returns the coded size, not the visible size. Subtract
the known padding from probed caps with the coded size before using them as
filter for caps negotiation with downstream elements.
https://bugzilla.gnome.org/show_bug.cgi?id=766382
The gst_v4l2_object_acquire_format() function is used by v4l2videodec to obtain
the currently set capture format. Since G_FMT returns the coded size, the
visible size needs to be obtained from the compose rectangle in order to
negotiate it with downstream elements. The G_CROP call hasn't worked on mem2mem
capture queues for a long time. Instead use the G_SELECTION call to obtain the
compose rectangle and only fall back to G_CROP for ancient kernels.
https://bugzilla.gnome.org/show_bug.cgi?id=766381
On modern kernels, the G/S_FMT ioctls will always fail using
V4L2_BUF_TYPE_VIDEO_OVERLAY with VFL_DIR_TX (e.g. real overlay out drivers)
since this is not the intented use (rather rx, according to v4l2 API doc).
Probably this is why the Video Output Overlay interface was created, so if
the driver advertises it we might as well use.
For old kernels (pre 2012) the old way might still work so keeping this for
compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=761165
Support for the updated V4L2_PIX_FMT_XRGB555 was added in commit
2538fee2fd however, when setting the format
for use in v4l2 ioctls, the old deprecated format is still used. Convert
this to the new accepted format type, as the preferred format.
https://bugzilla.gnome.org/show_bug.cgi?id=767300
Previously the segment.time was wrong, and the position was not updated
correctly, resulting in seeks in PUSH mode with upstream providing a BYTES
segment to not work at all.
https://bugzilla.gnome.org/show_bug.cgi?id=767157
This fixes seeking in DV streams where upstream operates in PUSH mode with a
TIME segment (e.g. avidemux). Without this, we would generate wrong durations
and timestamps after a seek.
https://bugzilla.gnome.org/show_bug.cgi?id=767157
When early returning in gst_soup_http_src_read_buffer() because the
element is FLUSHING, we need to unmap and unref the buffer which was just created.
https://bugzilla.gnome.org/show_bug.cgi?id=766718
Some endpoints (like Tandberg E20) can send BYE packet containing our
internal SSRC. I this case we would detect SSRC collision and get rid
of the source at some point. But because we are still sending packets
with that SSRC the source will be recreated immediately.
This brand new internal source will not have some variables incorrectly
set in its state. For example 'seqnum-base` and `clock-rate` values will be
-1.
The fix is not to act on BYE RTCP if it contains internal or unknown
SSRC.
https://bugzilla.gnome.org/show_bug.cgi?id=762219
Keeping the lock while emitting the stats signal introduces potential
deadlock in those situations when the signal callback wants the access
to rtpsession's properties which also requre the lock.
https://bugzilla.gnome.org/show_bug.cgi?id=762216
matroskademux would take the GST_OBJECT_LOCK in
- gst_matroska_demux_push_codec_data_all()
- gst_matroska_demux_query()
Some parse element such as FLAC checks upstream seekability, and
there is some use cases that matroska-demux is linked to a parse element
(e.g.,FLAC format) without intermediate elements (e.g., queue).
In this case, matroska-demux never returns from _push_codec_data_all()
because the parser can return only after it receives the response to
the upstream query, but that's not going to happen because it's
deadlocked.
Elements must not hold the object lock whilst pushing out events
or data.
https://bugzilla.gnome.org/show_bug.cgi?id=766645
