Returning FALSE because we drop an event means that
internal sources like qtdemux might throw an error
and break the whole pipeline. The only time it can
happen is either flushing or shutdown, and those
will be handled anyway.
This is a regression introduced by "03db374 - souphttpsrc: retry
request on early termination from the server"
The problem was that when seeking back to 0, we would not end up calling
add_range_header() which in addition to adding range headers *ALSO* sets
the read_position to the requested one.
This would result in a wide variety of later failures, like reading
again and again instead of stopping properly.
... and forward colorimetry to downstream. The Colour element describes
various color information (similar to 'colr' box in isobmff).
Note that, due to the comparatively limited syntax for color information
in vpx codecs, the color information in mkv/wemb container level
should be used for sophisticated color handling (e.g., HDR video).
https://bugzilla.gnome.org/show_bug.cgi?id=790023
The G722 payload only accepts G722 audio with channels=1, so it must
specify the encoding-params=1 in its src caps, otherwise it causes issues
with farstream which thinks it supports 2 channels G722 and when
confronted with a remote that has G722/8000/2, it will negotiate it
and error out with a not-negotiated when the caps don't intersect
at runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=789878
In MPLANE mode, the driver may set data_offset, which represent some
padding at the start of the buffer used internally. This portion of the
data need to be skipped, though it is included in bytesused.
This patch removes frame size sanity check as the method used will no
longer work. This check was simply there to help detect broken kernel
drivers. It would be re-implement by estimating the plane size, which is
not totally trivial and may be too much work for a simple debug check.
https://bugzilla.gnome.org/show_bug.cgi?id=733501
When XR packet is detected, warning message leads to misunderstandings.
Until RFC3611 is implemented in gst-plugins-base, the level needs to
be downgraded to avoid confusion.
https://bugzilla.gnome.org/show_bug.cgi?id=789746
It is possible that the mdat has more data than what was stored in the
headers file. If we put that to the output the file will have bogus data
at the end and some players will complain.
https://bugzilla.gnome.org/show_bug.cgi?id=784258
qtdemux.c: In function ‘gst_qtdemux_configure_stream’:
qtdemux.c:7764:34: error: suggest parentheses around ‘&&’ within ‘||’ [-Werror=parentheses]
if ((stream->n_samples == 1) && (stream->first_duration == 0)
~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avoid computing frame rate when a stream contain moof with only one
sample, to avoid an assert. The moof is considered as still picture.
The same is already done for one sample given in the moov.
https://bugzilla.gnome.org/show_bug.cgi?id=782217
Linear interpolation adds quite some noise, and it's unlikely that
anybody will ever need sub-sample accurate delays. Proper resampling
before that will lead to better results.
Issue an invalid VIDIOC_EXPBUF ioctl to the driver to check if the
driver supports dmabuf export. If the driver does not implement the
IOCTL, the error is ENOTTY. Any other error codes mean that the driver
implements VIDIOC_EXPBUF.
https://bugzilla.gnome.org/show_bug.cgi?id=779466
When a truncated FLV is provided and processed in pull mode, we
may endup trying to pull passed EOS, causing a rather confusing
warning as the pull offset is an integer overflow.
https://bugzilla.gnome.org/show_bug.cgi?id=787795
This code basically skip over codec_data with empty payload. In
this case, the codec_data variable is the size of the header for
the CODEC part of Video Tag. The remaining is supposed to be the
H.264 codec data, hence should not be empty.
https://bugzilla.gnome.org/show_bug.cgi?id=787795
