Add a new function to calculate video stream framerate which rely on
SPS, slice header and pic timing using formula:
time_scale 1 1
fps = ----------------- x --------------- x ------------------------
num_units_in_tick DeltaTfiDivisor (field_pic_flag ? 2 : 1)
See section E2.1 of H264 specification for definition of variables.
https://bugzilla.gnome.org/show_bug.cgi?id=723352
In a pipeline like so:
videotestsrc ! gleffects ! videoconvert ! sink
gleffects was simply passing the videoconvert bufferpool to videotestsrc
and not creating a glbufferpool. videobufferpool would then fail
to allocate from the glallocator.
From d4bcef3204 on, using a RGBA
texture to hold the data causes the glmemory to have half width
and a scaling of [2, 1]. Using a LA texture solves this problem
however cannot be attached to the framebuffer for copying into
a RGBA texture. Which will be solved by moving to EXT_texture_rg.
https://bugzilla.gnome.org/show_bug.cgi?id=728890
Previously it would only work if the alpha value was in the last
component (RGBx, BGRx). Now it works wherever the alpha value may
be (xRGB, xBGR, etc).
This fixes the OSX build and any builds with --disable-egl. That issue
was introduced in "glfilter: rewrite transform_caps to preserve caps fields".
https://bugzilla.gnome.org/show_bug.cgi?id=729861
Setting a scaled factor for X coordinate is not enough as the indexer
will still think stride is shorter and will not fully skip it. Instead,
update width, so the lines are as expected. Combined with the scale, it
will hide the cropped portion.
https://bugzilla.gnome.org/show_bug.cgi?id=729896
Fix a regression introduced recently with the lazy init.
It was happening when calling gst_video_gl_texture_upload_meta_upload
from an aplication. So not using gst_gl_upload_perform_with_buffer.
gst_video_frame_map() will store an updated video info base
on the video meta. In order to have the right stride and offset
we should update that video info accordingly.
The target texture of an EGLImage is the texture bind just
before calling glEGLImageTargetTexture2D.
As we currently only support a gl texture as the source of an EGLImage
the gl texture is actually already allocated when creating the eglimage.
I also see some cases where it fails to upload an eglimage when
glTexImage2D is called on the target.
GST_GL_WINDOW is used for window system specific choices.
An EGLDisplay can be created from window systems with egl support by using
eglGetDisplay().
https://bugzilla.gnome.org/show_bug.cgi?id=729551
This commit makes the loading of the GModules threadsafe, and
always first tries to load the symbol for the GL library that
is selected for the current context. Only then it falls back
to looking into the current module (NULL), and only as a last
resort the context specific function (e.g. eglGetProcAddress())
is called.
Also add configure parameters to select the names of the library
modules instead of using the defaults, and let the defaults be
independent of the G_MODULE_SUFFIX.
https://bugzilla.gnome.org/show_bug.cgi?id=728753
Previously, we used the width to determine the amount of data to be
copied using pbos. This, makes it allocate enough data for the
the strides as well.
Most of our 2D filters use the same simple vertex shader.
Also define the default fragment shader as the identity.
Avoid duplicating the same vertex and fragment shader text.
When parsing slice groups information for slice_group_map_type = 2, we
should only be reading up to num_slice_groups_minus1 groups since there
is always a "leftover" slice group and as many "foreground" slice groups
as needed.
This fixes parsing for SVCBMT-5 and SVCBMT-12 whereby the base layer would
have incorrectly been parsed to have up to 38 reference frames in list0,
which is not possible.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
When useDefaultScalingMatrixFlag is computed to be 1 while parsing
scaling_list(), then the scaling list shall be inferred to be equal
to the default list (7.4.2.1.1.1). That default list is really one
of Default_4x4_{Intra,Inter} or Default_8x8_{Intra,Inter} and not
one from fall-back rule sets A or B.
This fixes parsing for FRExt1_Panasonic_D, FRExt2_Panasonic_C,
FRExt3_Panasonic_E and FRExt4_Panasonic_B.
https://bugzilla.gnome.org/show_bug.cgi?id=724518
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
This should fix QoS problems, where basesink believed it was rendering with
20FPS but actually we were just queueing up X11 Expose events and only once
in a while something was rendered.
I was lucky that:
e1 = vc_dispmanx_element_add ()
eglCreateWindowSurface (e1)
vc_dispmanx_element_remove (e1)
e2 = vc_dispmanx_element_add ()
resulted in having e2 equal to e1. And also having the egl surface
that does not allocate its buffers before the first draw.
It avoids to draw to an invalid buffer.
Withtout this the default frame buffer is undefined:
glBindFramebuffer (GL_FRAMEBUFFER, 0)
Visually you could see some white frames at the beginning
when lunching videotestsrc ! glimagesink
With OpenGL Profiler from XCode you could see some
GL_INVALID_FRAMEBUFFER_OPERATION for the first frames
Import libvpx 1.3.0 range decoder files (dboolhuff.[ch]) to implement
the VP8 utilities native interface. Likewise, copy and use the default
libvpx generated entropy probabilities tables.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
"(NSApplication *)sharedApplication This method also makes a connection
to the window server and completes other initialization"
The implicit thing which is not mentioned is that it required
to be called in the main thread.
Fix a regression introduces by 82b7c915bb
When using with gst-launch, it was not possible to click on the close
cross of the window anymore which is a bit anoying and also because
it's was possible before.
Prior to this commit the GstGLContextCocoaClass was initialized
in the main thread because gst_gl_context_new was called in the
state change function from going from ready to paused.
From this commit this call is done from the streaming thread.
So that the call to [NSApplication sharedApplication];
was not done in the main thread anymore.
We now ensure that by assuming there is a GMainLoop running.
It's for debugging purpose so that's ok to do that. Also
note we already do this assumtion to run app itereations.
The regression had no consequence on the cocoa/videooverlay example
(that should be moved from gst-plugins-gl to -bad) because the
application is responsible for that necessary call.
This patch provides the basic infrastructure required for this.
Upload and Download has been ported to this.
Has the nice effect of allowing GstGLMemory to be our
refcounted texture object for any texture type (not just RGBA).
Should not lose any features/video formats.
It was originally test for 9 bytes (as the comment says) and was
rewritten buggily. So rewrite it a third way, which is now
hopefully consistent with the original and the comment, while
being more sense-making to humans.
Coverity 1139654
So this is actually pointless. We'll just have to ignore
Coverity moaning on those.
Revert "mpegts: test for allocation failure"
This reverts commit 224cb81b8f.
While it's unlikely to get there, it silences the coverity warning
on the error code path that we test for NULL before freeing, when
all branches there are from locations where pmt cannot be NULL,
and removing the NULL check makes the code more vulnerable to a
hypothetical future branch from somewhere where it can be.
Coverity 1139852
As the relevant variables are initialized to 0/NULL, we can loop
over the full range and make sure we free partial allocations
when an error happens partway through initialization.
Mesa, for example returns valid pointers for glGetIntegerv and
glGetStringi even if the gl version is less than that required for
both those functions to supposedly exist.
https://bugzilla.gnome.org/show_bug.cgi?id=727324
