The custom code is wrong as it ignores the templates, which leads to
missing fields in the result. Instead, simply use the default get_caps
implementation which does it correctly (get the template, intersect
with filter and return).
https://bugzilla.gnome.org/show_bug.cgi?id=749237
Without this, we will fixate weird pixel-aspect-ratios like 1/2147483647. But
in the end, all the negotiation code in videoaggregator needs a big cleanup
and videoaggregator needs to get rid of the software-mixer specific things
everywhere.
Caps refcounting was all wrong in this function. Rewrote it and add some
comments to make it clearer.
Fix caps leaks with the
validate.file.glvideomixer.simple.play_15s.synchronized scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=747915
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
Fix a caps leak with the
validate.file.glvideomixer.simple.play_15s.synchronized scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=747915
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
'array_buffers' contain borrowed GstBuffer and so shouldn't have a free
function. 'frames' is the one containing GstGLMixerFrameData and so should use
_free_glmixer_frame_data as free function.
Fix GstGLMixerFrameData leaks with the
validate.file.glvideomixer.simple.play_15s.synchronized scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=747913
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
In some upload implementations the out buffer has more than one references,
turning the buffer not writable, so it won't be possible to modify its
meta-data.
This patch moves the meta-data copy before increasing the reference of the out
buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=746173
glupload ! glcolorconvert ! sink
Some properties are manually forwarded. The rest are available using
GstChildProxy.
The two signals are forwarded as well.
It encapsulates a confiurable GL processing element in the
upload/colorconvert/download dance required to transparently process
the majority of GstBuffer's.
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
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
+ 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.
i686-apple-darwin11-llvm-gcc-4.2
gstglmixer.h:43: error: redefinition of typedef ‘GstGLMixer’
gstglmixerpad.h:32: error: previous declaration of ‘GstGLMixer’ was here
gstglmixer.h:46: error: redefinition of typedef ‘GstGLMixerFrameData’
gstglmixerpad.h:33: error: previous declaration of ‘GstGLMixerFrameData’ was here
The graphene-1.0 part should not be in the source code. This directory
is part of the cflags include. This is similar to gstreamer-1.0/
directory. This break compilation if the include directory where
graphene is installed is not in your include path.
Allows finer grain decisions about formats and features at each
stage of the pipeline.
Also provide propose_allocation for glupload besed on the supported
methods.
Make GstGLMemory hold the texture target (tex_target) the texture it represents
(tex_id) is bound to. Modify gst_gl_memory_wrapped_texture and
gst_gl_download_perform_with_data to take the texture target as an argument.
This change is needed to support wrapping textures created outside libgstgl,
which might be bound to a target other than GL_TEXTURE_2D. For example on OSX
textures coming from VideoToolbox have target GL_TEXTURE_RECTANGLE.
With this change we still keep (and sometimes imply) GL_TEXTURE_2D as the
target of textures created with libgstgl.
API: modify GstGLMemory
API: modify gst_gl_memory_wrapped_texture
API: gst_gl_download_perform_with_data
Depending on the platform, it was only ever implemented to 1) set a
default surface size, 2) resize based on the video frame or 3) nothing.
Instead, provide a set_preferred_size () that elements/applications
can use to request a certain size which may be ignored for
videooverlay/other cases.
A context can create a GLsync object that can be waited on in order
to ensure that GL resources created in one context are able to be
used in another shared context without any chance of reading invalid
data.
This meta would be placed on buffers that are known to cross from
one context to another. The receiving element would then wait
on the sync object to ensure that the data to be used is complete.
This gives more flexibility to the subclasses and permits to remove the
GstVideoAggregatorClass->disable_frame_conversion ugly API.
WARNING: This breaks the API as it removes the disable_frame_conversion
field
API:
+ GstVideoAggregatorClass->find_best_format
+ GstVideoAggregatorPadClass->set_format
+ GstVideoAggregatorPadClass->prepare_frame
+ GstVideoAggregatorPadClass->clean_frame
- GstVideoAggregatorClass->disable_frame_conversion
https://bugzilla.gnome.org/show_bug.cgi?id=740768
If we seek when media is in stop state, playback-test gives
critical error, since context of glimagesink is destroyed during stop.
But since context is not present, we need not handle send_event in glimagesink
Hence adding a condition to check if context is valid.
https://bugzilla.gnome.org/show_bug.cgi?id=740305
gst_glimage_sink_handle_events can be called from the overlay interface and from
the main thread before GL is setup. Before this change, that would call
_ensure_gl_setup() and deadlock on OSX.
Change things so that it's always safe to call gst_glimage_sink_handle_events()
without stuff deadlocking.
Remove gst_glimage_sink_handle_events call in gst_glimage_sink_init. It was
unnecessary and when the element was instantiated from the main thread, caused a
deadlock in OSX creating the context (thread).
with force-aspect-ratio=true, if the width or height changed, the
viewport wasn't being updated to respect the new video width and height
until a resize occured.
Otherwise, it is only possible for the sink pads and the src pads to
have the exact same caps features. We can convert from any feature
to another feature so support that.
Otherwise, it is only possible for the sink pads and the src pads to
have the exact same caps features. We can convert from any feature
to another feature so support that.
- update for shaders
- add alpha property
- image placement properties shamelessly borrowed from gdkpixbufoverlay
- image placement properties are GstController able
- use GstGLMemory for the overlay image data
- add support for gles2
Otherwise we could pass on a RGBA formatted buffer and downstream would
misinterpret that as some other video format.
Fixes pipelines of the form
gleffects ! tee ! xvimagesink
Allows callers to properly reference count the buffers used for
rendering.
Fixes a redraw race in glimagesink where the previous buffer
(the one used for redraw operations) is freed as soon as the next
buffer is uploaded.
1. glimagesink uploads in _prepare() to texture n
1.1 glupload holds buffer n
2. glimagesink _render()s texture n
3. glimagesink uploads texture n+1
3.1 glupload free previous buffer which deletes texture n
3.2 glupload holds buffer n+1
4. glwindow resize/expose
5. glimagesink redraws with texture n
The race is that the buffer n (the one used for redrawing) is freed as soon as
the buffer n+1 arrives. There could be any amount of time and number of
redraws between this event and when buffer n+1 is actually rendered and thus
replaces buffer n as the redraw source.
https://bugzilla.gnome.org/show_bug.cgi?id=736740
* aspect should not be 0 on init
* rename fovy to fov
* add mvp to properties as boxed graphene type
* fix transformation order. scale first
* clear color with 1.0 alpha
https://bugzilla.gnome.org/show_bug.cgi?id=734223
Dynamic pipelines that get and release the sink pads will finalize
the pad without going through gst_gl_mixer_stop() which is where the
upload object is usually freed. Don't leak objects in such case.
If window is resized, GstStructure pointer values have to be rescaled to
original geometry. A get_surface_dimensions GLWindow class method is added for
this purpose and used in the navigation send_event function.
https://bugzilla.gnome.org/show_bug.cgi?id=703486
The expected default behaviour for video sink is to maintain the
aspect ratio. Fix the default value to reflect this. The property
default was already TRUE, but the value was not initially TRUE.
Allows automatic negotiation of the size in the following case:
gst-launch-1.0 glvideomixer name=m sink_0::xpos=0 sink_1::xpos=320 ! glimagesink \
videotestsrc ! m. \
videotestsrc pattern=1 ! m.
https://bugzilla.gnome.org/show_bug.cgi?id=731878
This is too allow gst-launch debugging with multiple GL contexts as
well as avoiding segfaulting innocent gtk+ apps that have not called
XInitThreads.
https://bugzilla.gnome.org/show_bug.cgi?id=731525
The reshape property was never used.
Replace the draw property with a signal.
Based on patch by Mathieu Duponchelle <mathieu.duponchelle@epitech.eu>
https://bugzilla.gnome.org/show_bug.cgi?id=704507
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.
gst_gl_context_create() might need to dispatch some operations to the
application's main thread, and calling this in the change_state function
can cause deadlocks.
* picked from old libgstegl:
- GstEGLImageMemory
- GstEGLImageAllocator
- last_buffer management from removed GstEGLImageBufferPool
* add-ons:
- GstEGLImageMemory now old a reference on GstGLContext
so that it can delete the EGLImage and its gltexture source
while having the associated gl context being current.
- add EGLImage support for GstVideoGLTextureUploadMeta which
mainly call EGLImageTargetTexture2D
- GstGLBufferPool now supports GstEGLImageAllocator
- glimagesink / glfilters / etc.. now propose GstEGLImageAllocator
to upstream
https://bugzilla.gnome.org/show_bug.cgi?id=703343
Make buffer timestamps more accurate and, more importantly, actually
representative of the MIDI events timing.
Previously, buffers were only sent with timetamps aligned at a 10ms
boundary which was just wrong, now the buffer timestamp represents the
real time of the MIDI event.
Conveniently, the ALSA sequencer API supports scheduling events in the
future so the sequencer infrastructure can be used to have the tick
delivered at the right time, avoiding any custom scheduling mechanism.
The ticks scheduling starts on the first transition to PLAYING, and the
delay is also calculated when the pipeline goes into PLAYING.
https://bugzilla.gnome.org/show_bug.cgi?id=787683
When setting the "ports" property the value is duplicated but it's not
freed when the elements stops.
Reported by Valgrind (example run with "alsamidisrc ports=128:0"):
6 bytes in 1 blocks are definitely lost in loss record 30 of 1,911
at 0x4C2BBEF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5411528: g_malloc (gmem.c:94)
by 0x542A9FE: g_strdup (gstrfuncs.c:363)
by 0x775211E: gst_alsa_midi_src_set_property (gstalsamidisrc.c:284)
by 0x5184A4D: object_set_property (gobject.c:1439)
by 0x5184A4D: g_object_setv (gobject.c:2245)
by 0x51859DD: g_object_set_property (gobject.c:2529)
by 0x4F0474C: ??? (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1203.0)
by 0x4F065C8: ??? (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1203.0)
by 0x4F07557: ??? (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1203.0)
by 0x4EFE3EE: gst_parse_launch_full (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1203.0)
by 0x4EFE673: gst_parse_launchv_full (in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.1203.0)
https://bugzilla.gnome.org/show_bug.cgi?id=787683
We only need to initialize the mutex/cond once when creating the
element and then release them when we are done with the element.
Avoids weird "mutex_clear called when still locked" issues
There were still some races going on where seeking events wouldn't
be properly intercepted/executed by this thread.
* Instead of always waiting for the GCond to be emitted, first just
check if there is an event available
* Take ownership of the event *while* the lock is taken and not
after releasing/reacquiring it
* Finally acquire lock at the very top and release it at the end
to make it a bit more streamlined
This removes the remaining issues with seeks not being executed
The previous branch will release the lock in the call to
gst_ogg_demux_seek_back_after_push_duration_check_unlock()
Only unlock it if we didn't call that function
When calculating duration in push-mode we seek to a certain position
and discard any data until we get data from that requested position.
The problem is that basing ourselves solely on offset to determine
whether we reached the target offset is wrong since the source might
be fast enough to send us that target position *before* it processed
the requested seek.
This would end up in a situation where:
* We think we're done with duration estimate
* We fire a seek back to "0" in the loop thread
* We resume normal processing
* ... except that we're still getting data from too far ahead which
we decide to process.
* And we start doing totally wrong granule/time/duration calculation
and pushing wrong data.
Instead of this confusion, wait until we receive data from the requested
seek. We do that by using the fact that the seqnum in
seek_event_drop_til will be non-zero until the SEGMENT corresponding
to the requested SEEK has been received.
Bonus: makes startup slightly faster
Code using the push_loop_thread (using for sending seeks) assumes
that the thread was properly started, except that this isn't always
true and the thread might not have completely started.
Instead wait for the thread to properly start before doing anything
else.
If we are going to return a (potentially) 64bit integer, don't use
a 32bit one for calculation, otherwise we could end up exceeding
the maximum size of a 32bit int.
For stream mappers that don't set a specific granuleshift, it will
have the default value of -1.
Protect the code for that and return the granule value as-is
Since the default value of a GstOggPad.map.map was 0 ... we would
end up using wrong functions from mappers() if the stream wasn't
initialized yet.
Instead of that, use a default blank/empty first entry.
In some corner cases we end up with the building chain not being
properly tracked (and therefore not properly freed).
Add a FIXME so it can later be fixed, but for now just fix the leak
... as expected later on when end time is used to determine end running time.
Otherwise the latter is determined as NONE and the resulting text buffer is
then used indefinitely.
Fix various issues with reverse playback by clearing tracking
vars when working in reverse, and where possible using the
timestamp interpolation code to generate timestamps for
outgoing buffers. Make sure to mark things as discontinuous
only when looping backward to a new position and fix seeking
to the next page when starting.
In gst_ogg_demux_do_seek() when calculating the
keyframe time, account for a non-zero start-time
Handle a discontinuous first packet in
gst_ogg_demux_setup_first_granule() because that's pretty
normal after a seek. Also differentiate between a genuinely
truncated first packet and just bailing out early, by not using
granule = -1 as an error code.
Make the debug output logs clearer about which timestamps
are stream times (PTS) and which are ogg timestamps.
This is a followup commit to b95725c37e
* Resetting the decoder should only happen when we get a new initialization
header (0x01) and not on the other headers
* The initialized variable only gets set to TRUE once all headers have
been parsed. Also check if the vorbis_info struct has been properly resetted
also. Failure to do that would cause vorbisdec to error if it got
two initialization header in a row (the first would configure the underlying
library and the second one would error out because it's already initialized)
https://bugzilla.gnome.org/show_bug.cgi?id=779515
