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
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
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
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).
We were assigning to a guint64 value (frame->dts) the sum of a unsigned
and signed value... resulting it the result never being < 0.
Instead just check if it is smaller before assigning to frame->dts.
lame does internal resampling, but the base class only cares about
the number of raw samples, so tell finish frames about that, not
the number of samples in the outgoing frame.:
