120 bytes in 5 blocks are definitely lost in loss record 7,615 of 9,510
at 0x484486F: malloc (vg_replace_malloc.c:380)
by 0x58A2938: g_malloc (gmem.c:106)
by 0x58BA1F4: g_slice_alloc (gslice.c:1069)
by 0x588F059: g_list_prepend (glist.c:335)
by 0x5B9C5C0: select_best_master_clock (gstptpclock.c:756)
by 0x5B9CA8E: cleanup_cb (gstptpclock.c:1930)
by 0x589AD20: g_timeout_dispatch (gmain.c:4889)
by 0x589A4CE: UnknownInlinedFun (gmain.c:3337)
by 0x589A4CE: g_main_context_dispatch (gmain.c:4055)
by 0x58EE4E7: g_main_context_iterate.constprop.0 (gmain.c:4131)
by 0x5899A92: g_main_loop_run (gmain.c:4329)
by 0x5B9BA4C: ptp_helper_main (gstptpclock.c:1980)
by 0x58C8C31: g_thread_proxy (gthread.c:826)
576 bytes in 24 blocks are definitely lost in loss record 8,782 of 9,510
at 0x484486F: malloc (vg_replace_malloc.c:380)
by 0x58A2938: g_malloc (gmem.c:106)
by 0x58BA1F4: g_slice_alloc (gslice.c:1069)
by 0x588F059: g_list_prepend (glist.c:335)
by 0x5B9C5C0: select_best_master_clock (gstptpclock.c:756)
by 0x5B9EFA0: handle_announce_message (gstptpclock.c:934)
by 0x5B9EFA0: handle_ptp_message (gstptpclock.c:1765)
by 0x5B9EFA0: have_stdin_data_cb (gstptpclock.c:1851)
by 0x589A4CE: UnknownInlinedFun (gmain.c:3337)
by 0x589A4CE: g_main_context_dispatch (gmain.c:4055)
by 0x58EE4E7: g_main_context_iterate.constprop.0 (gmain.c:4131)
by 0x5899A92: g_main_loop_run (gmain.c:4329)
by 0x5B9BA4C: ptp_helper_main (gstptpclock.c:1980)
by 0x58C8C31: g_thread_proxy (gthread.c:826)
by 0x5DA4298: start_thread (pthread_create.c:481)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/857>
The peeked buffer was always reset after calling ::aggregate() but under
no other circumstances. If a pad was removed after peeking and before
::aggregate() returned then the peeked buffer would be leaked.
This can easily happen if pads are removed from the aggregator from a
pad probe downstream of the source pad but still in the source pad's
streaming thread.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/785>
While we can fixe the upstream latency using the min-upstream-latency, we
are now forced to use queues (hence more thread) in order to store the pending
data whenever we have an upstream source that has lower latency.
This fixes the issue by allowing to buffer the fixed upstream latency. This is
particularly handy on single core systems were having too many threads can
cause serious performance issues.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/684>
When going to PLAYING we will now have a clock and can stop waiting on
the condition variable and instead start waiting on the clock if
necessary for the current configuration.
In the other direction when going to PAUSED the clock might have
disappeared and we might need to wait on the condition variable again
instead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/653>
On the first buffer the base class would update the segment position
based on the start-time-selection. If the subclass provides its own
segment this will caused unexpected behaviour and override segment
information that was explicitly set by the subclass.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/600>
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/771
for context.
This exposes new API that subclasses must call from their
aggregate() implementation to signal that they have selected
the next samples they will aggregate: gst_aggregator_selected_samples()
GstAggregator will emit a new signal there, `samples-selected`,
handlers can then look up samples per pad with the newly-added
gst_aggregator_peek_next_sample.
In addition, a new FIXME is logged when subclasses haven't actually
called `selected_samples` from their aggregate() implementation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/549>
Make g-ir-scanner skip all those check macros that are
not useful for or usable from bindings.
gstcheck.h:209: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_message_error'
gstcheck.h:212: Warning: GstCheck: Unknown namespace for symbol 'assert_message_error'
gstcheck.h:251: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_int'
gstcheck.h:267: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_int'
gstcheck.h:280: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_int_hex'
gstcheck.h:299: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_int_hex'
gstcheck.h:310: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_int64'
gstcheck.h:327: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_int64'
gstcheck.h:340: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_int64_hex'
gstcheck.h:358: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_int64_hex'
gstcheck.h:369: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_uint64'
gstcheck.h:386: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_uint64'
gstcheck.h:399: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_uint64_hex'
gstcheck.h:417: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_uint64_hex'
gstcheck.h:428: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_string'
gstcheck.h:444: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_string'
gstcheck.h:455: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_float'
gstcheck.h:474: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_float'
gstcheck.h:487: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_pointer'
gstcheck.h:506: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_pointer'
gstcheck.h:517: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_clocktime'
gstcheck.h:534: Warning: GstCheck: Unknown namespace for symbol 'MAIN_START_THREADS'
gstcheck.h:547: Warning: GstCheck: Unknown namespace for symbol 'MAIN_START_THREAD_FUNCTIONS'
gstcheck.h:555: Warning: GstCheck: Unknown namespace for symbol 'MAIN_START_THREAD_FUNCTION'
gstcheck.h:626: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_CRITICAL'
gstcheck.h:628: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_CRITICAL'
gstcheck.h:640: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_WARNING'
gstcheck.h:652: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_OBJECT_REFCOUNT'
gstcheck.h:661: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_OBJECT_REFCOUNT_BETWEEN'
gstcheck.h:676: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_CAPS_REFCOUNT'
gstcheck.h:679: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_BUFFER_REFCOUNT'
gstcheck.h:682: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_MINI_OBJECT_REFCOUNT'
gstcheck.h:690: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_SET_STATE'
gstcheck.h:729: Warning: GstCheck: Unknown namespace for symbol 'tcase_skip_broken_test'
gstcheck.h:740: Warning: GstCheck: Unknown namespace for symbol 'tcase_skip_broken_loop_test'
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/579>
It was zero and in some condition it means that the control binding
values where ignored (as shown in the test). Setting it to MAXDOUBLE
so that the first time we sync the values from a a timestamp in the
right range the proper value is computed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/564>
In reverse playback, buffers have to be displayed at buffer.stop running
time, otherwise a same set of buffer can't be displayed in the exact opposite
order to forward playback.
For example, seeking a video stream at 1fps with start=0, stop=5s, rate=1.0
will display the following buffers:
b0.pts = 0s, b0.duration = 1s - at running time = 0s
b1.pts = 1s, b1.duration = 1s - at running time = 1s
b2.pts = 2s, b2.duration = 1s - at running time = 2s
b3.pts = 3s, b3.duration = 1s - at running time = 3s
b4.pts = 4s, b4.duration = 1s - at running time = 4s
<wait at EOS for 1second>
Now, playing that reverse with start=0, stop=5s, rate=1.0 has to display
the following buffers:
b0.pts = 4s, b0.duration = 1s - at running time = 0s
b1.pts = 3s, b1.duration = 1s - at running time = 1s
b2.pts = 2s, b2.duration = 1s - at running time = 2s
b3.pts = 1s, b3.duration = 1s - at running time = 3s
b4.pts = 0s, b4.duration = 1s - at running time = 4s
<wait at EOS for 1second>
With the previous code, it reproduced the following:
b0.pts = 4s, b0.duration = 1s - at running time = 1s
b1.pts = 3s, b1.duration = 1s - at running time = 2s
b2.pts = 2s, b2.duration = 1s - at running time = 3s
b3.pts = 1s, b3.duration = 1s - at running time = 4s
b4.pts = 0s, b4.duration = 1s - at running time = 5s
<NO WAIT AT EOS AND POST EOS RIGHT AWAY>
This is being tested with the `validate.launch_pipeline.sink.reverse_playback_clock_waits.*`
set of tests
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/450>
In reverse playback, buffers are played back from buffer.stop
(buffer.pts + buffer.duration) to buffer.pts, which means that the
position after the buffer is consumed is buffer.pts, not buffer.pts -
buffer.duration.
Without that change, and when `automatic_eos` feature is on,
we were dropping the last buffers as marking the stream EOS one buffer
too soon.
This is now being tested extensively by GstValidate in the
`validate.test.clock_sync.*` set of tests.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/450>
