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>
The meaning of the max latency is *not* the maximum latency this element will
introduce. It is the maximum latency this element can endure without
overflowing any buffers, which is infinite for x264enc.
Fixes latency configuration in zero latency mode, where max latency was
becoming 0... which usually won't work well if something else introduces
latency as then max < min in the end, and latency configuration just fails.
There is no reason x264enc should enforce a maximum allocation size.
The maximum is normally set by buffer pool which cannot grow, but we
don't offer a buffer pool. This would lead to stall when used with
element that don't implement allocation query.
Related to: https://bugzilla.gnome.org/show_bug.cgi?id=738302
We should give a chance to upstream to handle TIME seek events before trying
to handle it in asfdemux.
Fix a bug where fast backward seeks where discarded right away because they
were not supported by asfdemux.
https://bugzilla.gnome.org/show_bug.cgi?id=734471
For bytestream we don't want to expose it as codec_data but rather as
streamheader as it is not out-of-band data but data that should be
prepended to the beginning of the stream before the other buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=735070
Currently we only shift DTS to compensate that we don't support negative
timestamp. This cause a problem that PTS is no longer >= DTS and may
make muxers live much harder. Instead, shift both PTS/DTS forward. Also
remove all the hack to handle this which seems the result of thinking libx264
is bugged.
https://bugzilla.gnome.org/show_bug.cgi?id=731351
