gstrtspsrc.c:7939:11: error: implicit conversion from enumeration type 'GstSDPResult' to different enumeration type
'GstRTSPResult' [-Werror,-Wenum-conversion]
res = gst_sdp_message_new (&sdp);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
gstrtspsrc.c:7944:11: error: implicit conversion from enumeration type 'GstSDPResult' to different enumeration type
'GstRTSPResult' [-Werror,-Wenum-conversion]
res = gst_sdp_message_parse_uri (uri, sdp);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove pads from flow combiner and reset last
flow return to FLOW_OK by resetting the flow combiner.
This prevents FLOW_FLUSHING when trying to re-use the
demuxer after setting it back to NULL/READY state.
https://bugzilla.gnome.org/show_bug.cgi?id=737359
DTS delta is used to calculate sample duration. If buffer has missing DTS, we take either segment start or previous buffer end time, whichever is later.
This must only be done for non sparse streams, sparse streams can have gaps between buffers (which is handled later by adding extra empty buffer with duration that fills the gap)
https://bugzilla.gnome.org/show_bug.cgi?id=737095
packetized mode is being set when framerate is being set
which is not correct. Changing the same by checking the
input segement format. If input segment is in TIME it is
Packetized, and if it is in BYTES it is not.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
packetized mode is being set when framerate is being set
which is not correct. Changing the same by checking the
input segement format. If input segment is in TIME it is
Packetized, and if it is in BYTES it is not.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
packetized mode is being set when framerate is being set
which is not correct. Changing the same by checking the
input segement format. If input segment is in TIME it is
Packetized, and if it is in BYTES it is not.
https://bugzilla.gnome.org/show_bug.cgi?id=736252
Use XQueryPointer to check that the pointer is actually active inside
the capturing region.
This prevents drawing the cursor when the pointer is partially outside
of the captured region but not active inside the region; in particular
this avoids drawing the "window resize" cursor shapes to the captured
image when the mouse pointer crosses a window border.
NOTE that this is not only an optimization, this also happen to fix
a serious problem in multi-screen setups.
Because XFixes gives no information of what screen the pointer is on,
ximagesrc was always drawing the cursor on the captured screen even if
the mouse pointer was on another screen.
For example, when capturing from screen 1 (i.e. display-name=":0.1") the
cursor was drawn in the captured image even when the mouse pointer was
actually on screen 0, which is wrong and visually confusing.
https://bugzilla.gnome.org/show_bug.cgi?id=690646
When the cursor is partially or totally out of the capturing region on
the top side or on the left side, it gets drawn fully inside of the
region with its coordinates rounded up to the left or to the top border.
This is immediately noticeable when using the xid property to capture
a specific window.
To fix the issue, allow negative cx and cx coordinates when checking the
boundaries before drawing the cursor.
NOTE that the boundaries checking calculations still allows the cursor
to be drawn when it is only partially outside of the capturing region,
but this makes sense and gives a more pleasing visual behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=690646
XFixes provides the cursor coordinates relative to the root window, this
is not taken into account when using the xid property to capture
a specific window, the result is that the cursor gets drawn at the wrong
position.
In order to fix this consider the window location when calculating the
cursor position in the destination image.
https://bugzilla.gnome.org/show_bug.cgi?id=690646
In 1.0, we pass the complete caps to transform_caps to allow for better
optimizations. Make this function actually work on non-simple caps
instead of just ignoring the configured filter caps.
We have to skip 12 bytes of data for the chunk, and the data size
passed to the sub-chunk parsing functions should have 4 bytes less
than the data size.
Also when parsing the sub-chunks, check if we actually have enough
data to read instead of just crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=736266
This will prevent the converter to be picked automatically in case
someone implement dynamic converter selection support. I'd like this
to be ranked only for known device, as it's hard to be sure a device is
a converter suited for general purpose. Re-negotiation is also needed
before we can rank it.
https://bugzilla.gnome.org/show_bug.cgi?id=733607
Even though the UVC driver do a great deal of effort to prevent bad
timestamp to be sent to userspace, there still exist UVC hardware that
are so buggy that the timestamp endup nearly random. This code detect
and ignore timestamp from these drivers, making these camera usable.
This has been tested on both invalid and valid cameras, making sure it
does not trigger for valid cameras.
https://bugzilla.gnome.org/show_bug.cgi?id=732910
There is still around 18 drivers not yet ported to videobuf2. These driver
don't support freeing buffetrs through REQBUFS(0) hence for these the
memory type probing fails. In order to gain back our previous behaviour in
presence of these, we implement a workaround that assuming MMAP is
supported. Note that an allocator is only created for device with
STREAMING support in the device capabilities. In such case one of MMAP,
USERPTR and DMABUF is required. Though DMABUF came afterward, so is
not an option and in practice none of these drivers will only do USERPTR.
https://bugzilla.gnome.org/show_bug.cgi?id=735660
Also-by: Hans de Goede <hdegoede@redhat.com>
Since we can get the minimum number of buffers needed by an output
device to work, use it to set min_latency which will determine how many
buffers are queued.
https://bugzilla.gnome.org/show_bug.cgi?id=736072
