These parameters are incorrectly regarded as mutable in G-IR making them
"incompatible" with languages that are explicit about mutability like
Rust. In order to clean up the code and expected API there, update the
signatures here, right at the source (instead of overriding them in
Gir.toml and hoping for the best).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1005>
The XV_COLORSPACE attribute exists on some Xv adapters, with the same
semantics as the XV_ITURBT_709 attribute that was already supported.
A value of 0 is bt601, and 1 is for bt709 colorspace.
Fixes color shifting issues displaying bt709 content on some Xv
adapters.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/941>
ximagesink and xvimagesink use XkbKeycodeToKeysym when the key event is
received. However, this function returns NoSymbol if Xkb is unavailable.
This causes all key events to be translated to "unknown" key when running
ximagsink under some VNC.
Fix it by using XKeycodeToKeysym if Xkb is unavailable.
Use the new API to tell buffer consumers about alignment details.
This change is backward compatible as non ported elements can safely
ignore the alignment information and keep processing buffers as they use
to, copying if necessary.
I'm currently playing with modified ximagesink that does XGrabPointer()
in order to receive the mouse events occurred outside of the window and
send them to the navigation interface.
The pointer positions usually have positive coordinates, but it could
be negative with that change.
When the ximagesink handles XEvent that contains a negative pointer
coordinate, it incorrectly generates the GstEvent that contains an
extremely large positive pointer coordinate.
This is because the negative pointer position in XEvent is incorrectly
converted from signed to unsigned and passed as an argument to
gst_navigation_send_mouse_event() which causes implicit conversion from
integer to double. So the pointer position in the received XEvent and
generated GstEvent are completely different.
This potential problem does not seem to be a real problem with unmodified
ximagesink but there is no reason to leave it as is. This also fixes
xvimagesink that has the same potential problem.
https://bugzilla.gnome.org/show_bug.cgi?id=791140
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
If sanity checks on the buffer size allocated by XvShmCreateImage() fail,
call on g_set_error(), rather than just logging a warning, as this
failure is fatal.
Add a sanity check on buffer size when the video format is RGB. This adds to
existing checks on various YUV pixel formats.
https://bugzilla.gnome.org/show_bug.cgi?id=767712
libgstreamer currently exports some debug category
symbols GST_CAT_*, but those are not declared in any
public headers.
Some plugins and libgstvideo just use GST_DEBUG_CATEGORY_EXTERN()
to declare and use those, but that's just not right at
all, and it won't work on Windows with MSVC. Instead look
up the categories via the API.
Right now navigation events are being sent via gst_pad_send_event
after getting the peer pad of the sinkpad.
But the same functionality can be done using gst_pad_push_event
without need of getting peer pad in xvimagesink.
https://bugzilla.gnome.org/show_bug.cgi?id=752059
Sharing the internal pool results in situation where the pool may have
two upstream owners. This creates a race upon deactivation. Instead,
always offer a new pool, and keep the internal pool internal in case
we absolutely need it.
https://bugzilla.gnome.org/show_bug.cgi?id=748344
A previous patch increased allocations by 15 bytes in order to ensure
16 byte alignment for g_malloc blocks. However, shared memory is
already block aligned, and this extra 15 bytes caused allocation
to fail when we were already allocating to the shared memory limit,
which is a lot smaller than typical available RAM.
Fix this by removing the alignment slack when allocating shared
memory.
https://bugzilla.gnome.org/show_bug.cgi?id=706066
Video buffer pool will update video alignment to respect stride alignment
requirement. But haven't updated it to video alignment in configure.
Which will cause user get wrong video alignment.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=741501
Update the new buffer size after alignment in the pool configuration
before calling the parent set_config. This ensures that the parent knows
about the buffer size that we will allocate and makes the size check
work in the release_buffer method.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=741420
