When caps are already negotiated it should be possible to
select formats other than the one that was negotiated. If downstream
allows alpha video caps and it has already negotiated to a non-alpha
format, caps queries should still return the alpha caps as a possible
format as caps renegotiation can happen.
Includes tests (for compositor) to check that caps queries done after
a caps has been negotiated returns complete results
https://bugzilla.gnome.org/show_bug.cgi?id=757610
Don't wait until later, we want to know here if the codec can be opened or not
for the requested format. This was removed (accidentially?) by
119e09eac3
Without this decodebin has no way to switch to a different decoder if this one
does not work.
https://bugzilla.gnome.org/show_bug.cgi?id=762613
Remove calls to gst_pad_has_current_caps() which then go on to call
gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just
use gst_pad_get_current_caps() and check for NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=759539
Remove calls to gst_pad_has_current_caps() which then go on to call
gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just
use gst_pad_get_current_caps() and check for NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=759539
The code in the gst_dash_demux_parse_http_xsdate() was trying to
handle the case where the string is not null terminated by resizing
the buffer and appending a zero byte. This does not work if the buffer
is exactly the length of the string because the gst_buffer_resize()
function does not re-allocate the buffer, it just changes its size.
If a buffer is passed to gst_dash_demux_parse_http_xsdate() that is
exactly the length of the string, the function fails with an assert
failure in gst_buffer_resize().
https://bugzilla.gnome.org/show_bug.cgi?id=762148
Expose the expose() and set_render_rectangle() methods. These are useful for
proper functioning of the video overlay in various situations and toolkits.
Set fallback channel layout on files with more than two
channels. Not clear where to retrieve the real layout from
or what the default layout is for AIFF files, the spec
only seems to specify some layout for up to 6 channels
and the file in question doesn't have a CHAN chunk.
https://bugzilla.gnome.org/show_bug.cgi?id=676425
H.265 7.4.7.1 says:
> When slice_deblocking_filter_disabled_flag is not present, it is
> inferred to be equal to pps_deblocking_filter_disabled_flag.
https://bugzilla.gnome.org/show_bug.cgi?id=762351
This fixes a couple of issues regarding the output of (request)
per-program pads output:
We would never push out PAT sections (ok, that was one reallly stupid
mistake. I guess nobody ever uses this feature ...).
In the case where the PMT section of a program was bigger than one
packet, we would only end up pushing the last packet of that PMT. Which
obviously results in the resulting stream never containing the proper
(complete) PMT.
The problem was that the program is only started (in the base class)
after the PMT section is completely parsed. When dealing with single-program
pads, tsparse only wants to push the PMT corresponding to the requested
program (and not the other ones). tsparse did that check by looking
at the streams of the program...
... but that program doesn't exist for the first packets of the initial
PMT.
The fix is to use the base class program information (if it parsed the
PAT it already has some information, like the PMT PID for a given program)
if the program hasn't started yet.
In addition to the fact that it's a sane thing to do for multi-source
pad elements, it also avoids the situation where just using a request
pad (and not the main static pad) would result in the processing
stopping.
Currently the .la path is provided which requires to use libtool as
mentioned in the GStreamer manual section-helloworld-compilerun.html.
It is fine as long as the application is built using libtool.
So currently it is not possible to compile a GStreamer application
within gst-uninstalled with CMake or other build system different
than autotools.
This patch allows to do the following in gst-uninstalled env:
gcc test.c -o test $(pkg-config --cflags --libs gstreamer-1.0 \
gstreamer-gl-1.0)
Previously it required to prepend libtool --mode=link
https://bugzilla.gnome.org/show_bug.cgi?id=720778
Usually gl debug is initialized in gst_gl_context_create_thread.
But this function is not used when using the GstGLContextGPUProcess
from ChromiumGStreamerBackend.
Received signal 11 SEGV_MAPERR 000000000000
gst_debug_category_get_threshold
gst_gl_insert_debug_marker
gst_gl_base_filter_gl_start
CC libgstgl_x11_la-gstglcontext_glx.lo
In file included from gstglcontext_glx.c:39:0:
../utils/opengl_versions.h:52:43: error: ‘gles2_versions’ defined but not used [-Werror=unused-const-variable]
static const struct { int major, minor; } gles2_versions[] = {
^~~~~~~~~~~~~~
tsdemux is not able to handle negative playback rates.
But in mpegtsbase, the same check is not being done.
added a check to not handle negative rate while seeking unless
the same is handled upstream.
https://bugzilla.gnome.org/show_bug.cgi?id=758516
The plugin doesn't need the wayland-scanner package to be built
or run, it only needs the wayland-scanner program during compile time.
When cross-compiling, build systems might not have the wayland-scanner
package for the target system as it is a developer's tool, while it should
still be possible to use wayland-scanner from the host system.
This patch fixes it by not requiring the wayland-scanner package but
just the binary itself.
Note that the check is done outside of the PKG_CHECK_MODULES
as it doesn't work inside of it.
https://bugzilla.gnome.org/show_bug.cgi?id=752688