To passthrough crop-meta, the converter would need to allocate and
convert buffers of the size of the originating buffer. This is currently
made difficult by GstBaseTransform since we cannot alter the caps passed
though the allocation query. We would also need to wait for the first
input buffer to be received in order to make the decision around that
size.
So the short and safe solution is just to stop pretending we can
passthrought that meta.
https://bugzilla.gnome.org/show_bug.cgi?id=791412
If select-stream event was send to playbin3 as missing any GstStream of ES type
(V or A or TEX) of collection then, playbin will access to invalid address of
GstStream due to invalid index limit. This caused SIGSEGV.
https://bugzilla.gnome.org/show_bug.cgi?id=791638
The qt typefinder uses guint64 values for offset and size calculation
but the typefinder system only supports gint64 values.
Make sure we don't end up using potentially overflowing values.
The qt typefinder uses guint64 values for offset and size calculation
but the typefinder system only supports gint64 values.
Make sure we don't end up using potentially overflowing values.
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
Registering GstRTSPMessage as a boxed type allows it to be conveniently
used as an argument to signals, a-la GstSDPMessage, and general usage
from bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=762884
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
The while loop should end when all buffers "and" the preroll
buffer are consumed but this means to continue waiting if there
are still some pending buffers "or" preroll buffer.
The unit test was correct but racy because of this mistake.
I.e. because of the wrong "and" the while could finish too early.
cd tests/check && GST_CHECKS=test_query_drain make elements/appsink.forever
https://bugzilla.gnome.org/show_bug.cgi?id=789763
n_frames could end up being quite big (potentially up to G_MAXINT64). Which
would result in overflowing 64bits when multiplying it by GST_SECOND.
Instead move GST_SECOND to the num argument
If we are shutting down, don't spawn a cleanup thread to cleanup old
groups and instead queue them to be cleaned up in the state change
thread.
This avoids (hopefully for good) having a race between the state change
thread and other threads trying to deactivate elements/pads.
Deactivating pads from two threads isn't 100% MT-safe. There is a
slim chance that the GstPadActivateFunc might be called twice with
the same values (in this case from the cleanup thread *and* from
the GstElement change_state function when going from PAUSED to READY).
In order to avoid that, call any existing cleanup function *before*
calling the parent change_state implementation on downwards state
changes.
There is a race going on somewhere when we attempt to remove elements
*while* the parent container is switching to PLAYING.
In order to avoid this issue with discoverer, make sure we never
remove elements while switching to PLAYING.
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
When deactivating pads, we need to ensure that the streaming threads
going through the pads we wish to deactivate can cleanly return.
Failure to do that would result in the streaming locks of those
pads never being released. The end result would be a deadlock
when stopping decodebin2.
In order to avoid that situation, release the "dyn" lock around
the deactivation code. And refactor the code to cope with the
list of blocked pads having potentially changed when re-acquiring
the lock.
