Instead of using extra plane, we encode the number of tiles in x and y in the stride of
each planes (i.e. y_tiles << 16 | x_tiles) and introduce tile_mode, tile_width and
tile_height into GstVideoFormatInfo structure.
https://bugzilla.gnome.org/show_bug.cgi?id=707361
For reverse playback, the segment event will only be pushed when
the first buffer is actually pushed. But for decoding frames and storing
those into the list to be pushed the output_segment.rate value is used
to determine if it is forward or reverse playback.
In case a previous segment event (or none) is in use it will mistakenly
think it is doing forward playback and push the buffers immediatelly and
try to clip buffers based on an old segment (or an uninitialized one, leading
to an assertion)
This patch fixes this by copying the segment earlier if on reverse playback
https://bugzilla.gnome.org/show_bug.cgi?id=721666
And don't assume in other code that set_format() preserves any fields at
all. These assumptions were already made here for fields that were changed
by set_format().
Fixes "Unitialized Scalar Variable" issues reported by Coverity.
Has the added advantage of detecting whether somebody *does* use those
fields (ending up with a invalid address).
https://bugzilla.gnome.org/show_bug.cgi?id=720810
This must only ever be used in caps in combination with a non-system
memory GstCapsFeatures, and where it does not make sense to specify
any of the other video formats. Examples of this would be in gst-vaapi.
This reverts commit 5fcdabd907.
Instead of making it impossible to use the ENCODED format we should
just document that it must not be used for capsfeature-less caps.
Also this commit broke API/ABI.
GST_VIDEO_FORMAT_ENCODED was added to support *extracting* video-related
information (like width, height, framerate,...) from caps.
It is __NOT__ intended to be used as a format field on video/x-raw caps.
So that it avoids to send an allocation query twice.
One from an early call to gst_video_encoder_negotiate from a
subclass, then one from gst_video_encoder_allocate_output_frame.
Which means that previously gst_video_encoder_negotiate was not
clearing the GST_PAD_FLAG_NEED_RECONFIGURE even on success.
Fixes bug https://bugzilla.gnome.org/show_bug.cgi?id=719684
... so subclasses can release a frame all the way (also from frame list)
without having to pass through _finish_frame or _drop_frame.
The latter may not be applicable, or may or may not have already
been called for the frame in question.
See https://bugzilla.gnome.org/show_bug.cgi?id=693772
allows configuration of whether GstVideoGLTextureUploadMeta is
added to buffers resulting from a buffer pool. This is sperate
to the caps feature in that an element may want to add the upload
meta itself rather than allowing the buffer pool to.
https://bugzilla.gnome.org/show_bug.cgi?id=712798
We could have allocation query before caps event and even without caps inside
the query. In such cases , the downstream can return a bufferpool object with
out actually configuring it. This feature is helpful to negotiate the bufferpool
with out knowing the output video format. For eg: some hardware accelerated
decoders can interpret the o/p video format only after it finishes the decoding
of one buffer at least.
https://bugzilla.gnome.org/show_bug.cgi?id=687183
