Slight change in semantics for convenience. Shouldn't cause any
problems since this function is usually only used on pre-filtered
caps and not random caps, and it's hard to imagine a situation
where someone would want to rely on the previous behaviour.
Basic API to attach overlay rectangles to buffers,
or blend them directly onto raw video buffers.
To be used primarily for things like subtitles or
logo overlays, not meant to replace videomixer.
Allows us to associate subtitle overlays with
non-raw video surface buffers, so that subtitles
are not lost and can instead be rendered later
when those surfaces are displayed or converted,
whilst re-using all the existing overlay plugins
and not having to teach them about our special
video surfaces. Could also have been made part
of the surface buffer abstraction of course, but
a secondary goal was to consolidate the blending
code for raw video into libgstvideo, and this
kind of API allows us to do both in a way that's
minimally invasive to existing elements, and at
the same time is fairly intuitive.
More features and extensions like the ability to
pass the source data or text/markup directly will
be added later.
https://bugzilla.gnome.org/show_bug.cgi?id=665080
API: gst_video_buffer_get_overlay_composition()
API: gst_video_buffer_set_overlay_composition()
API: gst_video_overlay_composition_new()
API: gst_video_overlay_composition_add_rectangle()
API: gst_video_overlay_composition_n_rectangles()
API: gst_video_overlay_composition_get_rectangle()
API: gst_video_overlay_composition_make_writable()
API: gst_video_overlay_composition_copy()
API: gst_video_overlay_composition_ref()
API: gst_video_overlay_composition_unref()
API: gst_video_overlay_composition_blend()
API: gst_video_overlay_rectangle_new_argb()
API: gst_video_overlay_rectangle_get_pixels_argb()
API: gst_video_overlay_rectangle_get_pixels_unscaled_argb()
API: gst_video_overlay_rectangle_get_render_rectangle()
API: gst_video_overlay_rectangle_set_render_rectangle()
API: gst_video_overlay_rectangle_copy()
API: gst_video_overlay_rectangle_ref()
API: gst_video_overlay_rectangle_unref()
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We'll change these
over to the new API once we depend on glib >= 2.32.
Replace g_thread_create() with g_thread_try_new().
Make out args to gst_video_event_parse_{downstream|upstream}_force_key_unit
optional, update libgstvideo.def and fix docs a bit.
API: gst_video_event_new_upstream_force_key_unit
API: gst_video_event_new_downstream_force_key_unit
API: gst_video_event_is_force_key_unit
API: gst_video_event_parse_upstream_force_key_unit
API: gst_video_event_parse_downstream_force_key_unit
https://bugzilla.gnome.org/show_bug.cgi?id=607742
Now we can configure how much time to wait before deciding that a
discont has happened.
Also, adds getter and setter to allow derived implementations to set
this value upon construction.
Suggestions and several improvements by Havard Graff.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
A common problem for audio-playback is that the timestamps might not
be completely linear. This is specially common when doing streaming over
a network, where you can have jittery and/or bursty packettransmission,
which again will often be reflected on the buffertimestamps.
Now, the current implementation have a threshold that says how far the
buffertimestamp is allowed o drift from the ideal aligned time in the
ringbuffer. This was an instant reaction, and ment that if one buffer
arrived with a timestamp that would breach the drift-tolerance, a resync
would take place, and the result would be an audible gap for the
listener.
The annoying thing would be that in the case of a "timestamp-outlier",
you would first resync one way, say +100ms, and then, if the next
timestamp was "back on track", you would end up resyncing the other way
(-100ms) So in fact, when you had only one buffer with slightly off
timestamping, you would end up with *two* audible gaps. This is the
problem this patch addresses.
The way to "fix" this problem with the previous implementation, would
have been to increase the "drift-tolerance" to a value that was greater
than the largest timestamp-outlier one would normally expect. The big
problem with this approach, however, is that it will allow normal
operations with a huge offset timestamp vs running-time, which is
detrimental to lip-sync. If the drift-tolerance is set to 200ms, it
basically means that lip-sync can easily end up being off by that much.
This patch will basically start a timer when the first breach of
drift-tolerance is detected. If any following timestamp for the next n
nanoseconds gets "back on track" within the threshold, it has basically
eliminated the effect of an outlier, and the timer is stopped. If,
however, all timestamps within this time-limit are breaching the
threshold, we are probably facing a more permanent offset in the
timestamps, and a resync is allowed to happen.
So basically this patch offers something as rare as both higher
accuracy, it terms of allowing smaller drift-tolerances, as well as much
smoother, less glitchy playback!
Commit message and improvments by Havard Graff.
Fixes bug #640859.
