... which no longer worked due to unconditionally clearing sample info and
ending up in inconsistent state. Let's tread a bit more carefully and also
allow for the old seek handling that resorts to scanning if no mfra info
is available.
Add a couple of useful debug traces , they happened to be useful to
debug/investigate a 4K video playback issue with v4l2, so let's make these
changes more permanent.
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
https://bugzilla.gnome.org/show_bug.cgi?id=785109
Since 1.6, the transfer function for BT2020 has been changed from BT709
to BT2020_12. It's the same function, but with more precision. As a side
effect, the V4L2 colorpsace didn't match GStreamer colorspace. When
GStreamer ended up making a guess, it would not match anything supported
by V4L2 anymore. This this by using BT2020_12 for BT2020 colorspace and
BT2020 transfer function in replacement of BT709 whenever a 4K
resolution is detected.
The pixel aspect ratio is documented to not change unless the TV
Standard is changed. So this mean that this will be uniform across all
possible format and resolutions.
https://bugzilla.gnome.org/show_bug.cgi?id=784674
First step of a larger cleanup, all function from v4l2_calls are in fact
methods on GstV4l2Object. This split makes the code really confusing.
This also remove no longer unused macros.
Before that, each m2m node would be wrapped as a single, multi-format
decoder element. As a unique name was needed, we where using the device
name, which changes between re-boots. This led to unpredictable element
names. In this patch, we generate an element per codec, using
v4l2<codec>dec name. If there is multiple decoder for the same format,
the following elements will be named v4l2<node><codec>dec.
https://bugzilla.gnome.org/show_bug.cgi?id=784908
Instead of just sending a sticky event with them downstream. This allows
getting the HTTP headers easily in the application, and especially also
on errors.
Do not allocate payload size outbuf if appending payload buffer.
The commit 137672ff18 attached payload
to the output buffer but forgot to remove payload allocation. That
effectively doubled payload size and add zero'ed or random bytes.
Makes the following pipeline work again:
gst-launch-1.0 -v audiotestsrc wave=2 ! gsmenc ! rtpgsmpay ! rtpgsmdepay ! gsmdec ! autoaudiosink
https://bugzilla.gnome.org/show_bug.cgi?id=784616
Soup allows only up to two connections per host in a session,
if we use default value. When session sharing is used, however,
more connections might be required in a session.
(e.g., multi-audio adaptive streaming case)
https://bugzilla.gnome.org/show_bug.cgi?id=784495
gst_util_uint64_scale_int takes a gint as denom parameter
whereas ctx->clock_rate is a guint32.
It happens when gst_rtp_packet_rate_ctx_reset set clock_rate
to -1.
So just define clock_rate as gint like it is done in rtpsource.h
https://bugzilla.gnome.org/show_bug.cgi?id=784250
When resurrecting a buffer, the subsequent free call can result
in the group-released handler being called again, which causes
a recursive loop. This patch blocks the signal handler during
the time that it executes, ensuring that the loop will not occur.
https://bugzilla.gnome.org/show_bug.cgi?id=759292
SoupSession's ssl-ca-file property is deprecated. Use the recommended
tls-database property.
This is a bit more complex as it requires creating a GTlsFileDatabase
object for an absolute (!) path to the CA certificates file.
https://bugzilla.gnome.org/show_bug.cgi?id=784005
Recent GnuTLS disregards the Common Name and only looks at the Subject
Alternative Name extension. Since our test-cert has no SAN extension,
validation fails.
Generate a new certificate with SAN. In addition to 127.0.0.1, for good
measure make it valid for localhost and ::1, too.
https://bugzilla.gnome.org/show_bug.cgi?id=784005
Currently we only allowed HTTP proxy. Don't filter for the scheme, just check
if it looks like an URI. Soup will warn if the URI is invalid or if
proxy protocol is not supported. This enables using SOCKS 4/5 which is
directly implemented into GIO.
https://bugzilla.gnome.org/show_bug.cgi?id=783012
Increasing this number fix a buffer starvation problem I'm hitting
with a "v4l2src ! kmssink" pipeline.
kmssink requests 2 buffer as it keeps a reference on the last rendered
one. So we were allocating 3 buffers for the pipeline.
Once the first 2 buffers have been pushed we ended up with:
- one buffer queued in v4l2
- one being pushed
- one kept as last rendered
If this 3rd buffer is released after that v4l2 used the first one to
capture we end up with a buffer starvation problem as no buffer is currently
queued in v4l2 for capture.
Fixing this by adding one extra buffer to the pipeline so when one
buffer is being pushed downstream the other can already be queued to
capture the next frame.
We were already adding 3 buffers if downstream didn't reply to the
allocation query. I reduced this number to 2 to compensate the extra
buffer which is now always added.
https://bugzilla.gnome.org/show_bug.cgi?id=783049
This patch fixes a memory leak that is caused if the dmabuf file
descriptor dup fails. Previously, _cleanup_failed_alloc() would
not unref the memory because mems_allocated had not yet been
incremented.
https://bugzilla.gnome.org/show_bug.cgi?id=784302
