Chaining a downstream pool would lead to two owner of the same
pool. In dynamic pipeline, if one owner is removed from the pipeline
the pool will be stopped, and the rest of the pipeline will fail
since the pool will now be flushing. Also fix proposed pool caching,
filter->pool was never set, never unrefed.
https://bugzilla.gnome.org/show_bug.cgi?id=745705
GLImage does not use any kind of internal pool. There was some
remaining code and comment stating that it was managing the
pool, and it was in fact setting the active state when doing
to ready state.
* Only create the pool if requested and in propose_allocation
* Cache the pool to avoid reallocation on spurious reconfigure
* Don't try to deactivate the pool (we don't own it)
https://bugzilla.gnome.org/show_bug.cgi?id=745705
LibJPEG uses macroblock of 8x8 sample. In this element we use RGB and
Y444, two 24bit formats that are stored in 32bit pixels. This mean we
have 32x32 bytes macroblocks. For this reason, we need to allocate
our buffer slightly larger. We also need to pass the line pointer in
the right order, otherwise the image endup upside-down.
https://bugzilla.gnome.org/show_bug.cgi?id=745109
Otherwise the pipeline stalls when running
more than one glimagesink with gst-launch.
Also only register the custom nsapp loop
when setting up the nsapp from gstgl.
We also need to recalculate the offset, since otherwise the frame
mapping will be forward two lines in the U and V planes (I420) due
to gst_video_info_align() round up the Y plane to a even number of
lines.
https://bugzilla.gnome.org/show_bug.cgi?id=745054
Make sure we support offset and video alignment when downloading too.
This is currently not used (plane_start is always 0), but it makes
the code correct if we want to use that later.
Provide the right size to GL when uploading. Using maxsize is wrong
since we offset the data point with the memory offset and video
alignement offset.
https://bugzilla.gnome.org/show_bug.cgi?id=744246
When the memory is partial copy, the texture size and videoinfo no
longer make sense. As we cannot guess what the application wants, we
safely copy into a sysmem memory.
https://bugzilla.gnome.org/show_bug.cgi?id=744246
This implements support for GstAllocationParams and memory alignments.
The parameters where simply ignored which could lead to crash on
certain platform when used with libav and no luck.
https://bugzilla.gnome.org/show_bug.cgi?id=744246
When trying to render buffers with meta:GLTextureUpload the glimagesink crashes
with a segmentation fault.
This patch workarounds this crash setting to NULL the method implementation
after free.
https://bugzilla.gnome.org/show_bug.cgi?id=745206
+ Split headers from source
+ Remove uneeded AM_CFLAGS, AM_LDFLAGS
+ Always set OBJCFLAGS
Due to the presence of a .m and regardless of the conditional values,
automake will promote the link command to OBJC using OBJCFLAGS. Only
the basic flags (like warnings and optimization) are going to make a
difference though.
This cleanup builds up the makefile with less specific files first
toward more specific file. FLAGS are built with the basic that unused
flags will have empty variable.
When setting a new window handle, we need to ensure all implementations
will detect the change.
For that we deactivate the context before setting the window handle, then
reactivate the context
https://bugzilla.gnome.org/show_bug.cgi?id=745090
When (re)activating the context, the backing window handle might have changed.
If that happened, destroy the previous surface and create a new one
https://bugzilla.gnome.org/show_bug.cgi?id=745090
This fix a very slow rendering rate regression that only
happens when using gst-launch, i.e. in the case where
the main thread does not run any NSApp loop.
Git bisect reported it has been introduced by the commit
e10d2417e2:
"move to CGL and CAOpenGLLayer for rendering".
Then the commit 7d46357627:
"gstglwindow_cocoa: fix slow render rate" attempted to fix
the slow rendering rate problem when using gst-launch.
At least for me it does not work. I tried several
combinations, for example to flush CA transactions in the
custom app loop, as mentioned in the doc, but the only solution
that fixes the slow rendering is by reducing the loop latency.
From what I tested, no need to put less than 60ms, even if the
framerate has an interval much lower (16.6ms for 60 fps).
