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
The parameter type was wrongly documenting that a GstVideoInfo structure
pointer was needed, while it needs a GstVideoFormatInfo structure
pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=764414
P010 is a YUV420 format with an interleaved U-V plane and 2-bytes per
component with the the color value stored in the 10 most significant
bits.
https://bugzilla.gnome.org/show_bug.cgi?id=761607
---
Changes since v2:
- Set bits=16 in DPTH10_10_10_HI
Changes since v1:
- Fixed x-offset calculation in uv.
- Added 6-bit shifts to FormatInfo.
libgstreamer currently exports some debug category
symbols GST_CAT_*, but those are not declared in any
public headers.
Some plugins and libgstvideo just use GST_DEBUG_CATEGORY_EXTERN()
to declare and use those, but that's just not right at
all, and it won't work on Windows with MSVC. Instead look
up the categories via the API.
gst_pad_get_allowed_caps() will return NULL if the srcpad has no peer.
In that case, use gst_pad_peer_query_caps() with template caps as filter
to have negotiated output caps properly before forwarding GAP event.
https://bugzilla.gnome.org/show_bug.cgi?id=761218
Add missing ':' to tile_ws and tile_hs fields documentation to avoid
bad render of these two fields, mark reserved bytes as private to hide
field and avoid gtkdoc warning and add parameters description to
documented macro to avoid gtkdoc warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=761132
In gst_video_info_to_caps(), make sure we end up with an RGB matrix for
RGB formats and warn when the GstVideoInfo colorimetry is wrong.
In gst_video_info_from_caps(), fix the GstVideoInfo with an RGB matrix
for RGB formats and warn about inconsistent caps.
See https://bugzilla.gnome.org/show_bug.cgi?id=759624
For RGB formats, the matrix in the colorimetry (conversion from YUV to
RGB) is irrelevant and we should ignore it and assume the identity
transform for everything we do.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=759624
In the case where the stream doesn't have a framerate set and the frames
don't have a duration set, we still want to use the clipping path to
make sure we don't push buffers outside of the segment.
The problem was the previous iteration was setting a duration of 2s, which
meant that any buffer which was less than 2s before the segment start would
end up getting pushed.
Instead, use a saner 40ms (25fps single frame duration) to figure out whether
the frame could be within the segment or not
v210, UYVP and IYU1 are complex formats for which pixel stride does not really
have a meaning. If we copy width*pstride bytes per line, it's not going to do
the right thing. As a fallback, copy stride bytes per line. This might copy
uninitialized bytes at the end of each line, but at least copies the frame.
https://bugzilla.gnome.org/show_bug.cgi?id=755392
Before we just merged everything in pretty much random ways
ad-hoc instead of keeping state properly. In 0.10 that was
how it worked, but in 1.x the tag events sent should always
reflect the latest state and replace any previous tags.
So save the upstream (stream) tags, and save the tags set
by the decoder subclass with merge mode, and then update
the merged tags whenever either of those two changes.
This slightly changes the behaviour of gst_video_decoder_merge_tags()
in case it is called multiple times, since now any call replaces
the previously-set tags. However, it leads to much more predictable
outcomes, and also we are not aware of any subclass which sets this
multiple times and expects all the tags set to be merged.
If more complex tag merging scenarios are required, we'll have
to add a new vfunc for that or the subclass has to intercept
the upstream tags itself and send merged tags itself.
https://bugzilla.gnome.org/show_bug.cgi?id=679768
Apparently I forgot how gobject works, there is no need to expose
it directly as one can call it from the parent_class pointer
This reverts commit ea9b6a7e3c.
