This allow using external pools that have different strides from the
default. These strides need to respect certain rules, which we check
and if these are not met, we fallback to generic pool.
https://bugzilla.gnome.org/show_bug.cgi?id=735379
This is a rewrite of the pool negotiation and configuration. Direct
to output decoding is now achieved by configuring the pool using
video-alignment. This removes copies when dealing with any elements that
supports VideoAlignment, and enable usage of generic video buffer pool,
XVImagePool and GLPool. It drops the crop meta implementation for now.
https://bugzilla.gnome.org/show_bug.cgi?id=735379
A pipeline like:
gst-launch-1.0 filesrc location=file.ts ! tsdemux ! mpegvideoparse ! mpeg2dec ! vaapisink
would look bad when file.ts contains 704x576 video, because vaapisink would
give you buffers of stride 768, but libmpeg2 was not told about this and
used a stride of 704.
Tell libmpeg2 about the stride from downstream; in the process, teach it to
reject buffer pools that don't meet libmpeg2's chroma stride requirements
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
New changes to gstvideo will reset all the video info state
when calling _set_format, overwriting what was previously set
in the preceding code.
The comment says the following code is meant to preserve the
pre-crop size, so let's just keep the size and related data
as this does not seem to break anything else (this is what
the _set_format call would have set before the change that
reset all data, except the colorimetry).
If the sequence is not flagged as progressive its buffers are marked
interlace mode mixed. There is an individual picture flag indicating
whether picture in the sequence are interlaced or not. This is used
along with the new GST_VIDEO_BUFFER_FLAG_INTERLACED to correctly and
completely indicate the buffer's interlaced state.
Also, TFF and RFF should only be set if the sequence is not progressive.
When mpeg2dec needs to do cropping (because downstream can't handle it),
we need temporary buffers to decode to.
Use the user_data field to store those, and unify the rest of the code
that needs to touch a buffer (regardless of how/where it was allocated).
https://bugzilla.gnome.org/show_bug.cgi?id=680194
