Whereas the previous default 0 was backwards compatible in that it lead
to erroring out immediately upon any error, elements that are really
ported and using the base class error macro can be assumed to intend to
improve behaviour rather than maintaining the old one. So, make it easy
on those and any future one and tolerate some errors by default, as intended.
Fixes#666579.
Remove interlaced boolean from caps and replace with an interlace-mode enum.
document this new property in the video caps document. With the enum we can
put fields into separate video meta.
Add enum for this interlace-mode in the VideoInfo.
Update the buffer flags.
When using g_convert, we should only pass the length
of the string content (without the \0) as g_convert will
only parse the real contents when changing formats. Including
the \0 causes it to add another \0, increasing the string
size when not needed.
For example, when writting a North geo location ref entry, that should
be a string with a single N letter, it would write:
"N\0\0", causing the string to have size 3, instead of 2 as expected.
In our case, we can pass -1 and let g_convert calculate the strlen as
we don't use the length anywhere else.
This fixes jifmux's tests on gst-plugins-bad.
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().
gst_tag_image_data_to_image_buffer() ->
gst_tag_image_data_to_image_sample() And make it return a GstSample.
Store the image-type into the extra sample info.
Remove a deprecated tag
Make appsink return a GstSample. Remove the pull_buffer_list method because it
is not very useful anymore.
Pass GstSample to the conversion function.
Update playbin2 and examples
Remove old useless caps code.
Make a negotiate function and use the configured caps as the caps on the appsrc
pad. If nothing was configured, fall back to the parent implementation.
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
Originally decodebin couldn't deal with that in 0.10, but now simply
setting the caps when we know them should be enough. Pad activation
mode switching might need some more testing/tweaking with the new
arrangement.
gst_basertppayload -> gst_base_rtp_payload
Add pts/dts support in the depayloader
Remove old timestamp code
Add a default getcaps function so subclasses can chain up to it instead of
relying on the return value of the getcaps function.
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.
