`@` references are used to reference function parameters, struct members
or enum variants _within_ the current type/function. It cannot and
should not be used to reference to types outside that.
Since C has no notion of member functions it makes little sense to
prefix these with `@`; most of the documentation here was referencing
functions on _different_ types anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1090>
This can be used by subclasses to mark output frames as known to be
corrupted, for example if reference frames were missing. ffmpeg's
decoders can signal this.
In addition this flag is propagated downstream if the input frame had it
set.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/730>
Also not optimal but at least simplifies the code a bit and doesn't
require g_list_length() and g_list_append() in a few places.
For 2.0 there are some more candidates to change but unfortunately
they're currently part of the API.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/683>
Introduce a new API so encoders can split the encoding in subframes.
This can be useful to reduce the overall latency as we no longer need to
wait for the full frame to be encoded to start decoding or sending it.
Since we started depending on GLib 2.44, we can be sure this macro is
defined (it will be a no-op on compilers that don't support it). For
plugins we should just start using `G_DECLARE_FINAL_TYPE` which means we
no longer need the macro there, but for most types in base/gst-libs we
don't want to break ABI, which means it's better to just keep it like it
is (and use the `#ifdef` instead).
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
Since the allocation query caps contains memory size and the pad's caps
contains the display size, a video encoder or decoder might need to allocate
a different frame size than the size negotiated in the caps.
This patch splits this logic distinction for videodecoder and videoencoder.
The user if needs a different allocation caps, should set the allocation_caps
in the GstVideoCodecState before calling negotiate() vmethod. Otherwise the
allocation_caps will be the same as the caps set in the src pad.
https://bugzilla.gnome.org/show_bug.cgi?id=764421
Monitor for reordered output timestamps, and then avoid oldest DTS
as PTS approach, and try for an oldest PTS as out PTS approach,
if at least all valid PTS available.
Avoids bogus estimating upon sparse available input PTS, and tries
to handle all-keyframe input, or input PTS which are actually DTS.
... by having some more timestamp tracking in a private frame field.
Not doing so would lead to (a.o.) losing the needed minimum timestamp in
an earlier sent frame.
Unifies the code and ensures that:
* subclasses needing to use the frame_number on a void* field will
always work
* wraparounds will be automatically taken care of if we have to deal
with more than 2**32 frames
