Having an unlimited input queue is very bad if the
encoder can't run at real-time. Eventually it will
consume all RAM. I don't really see any reason to
have more than 1 outstanding encoded frame, so
remove the queue and limit things to 1 pending frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2499>
Original commit message from CVS:
Patch by: Mark Nauwelaerts <manauw at skynet dot be>
* configure.ac:
Clean up detection of different mjpegtoolsAPI versions.
* ext/mpeg2enc/gstmpeg2enc.cc:
* ext/mpeg2enc/gstmpeg2enc.hh:
* ext/mpeg2enc/gstmpeg2encoder.cc:
* ext/mpeg2enc/gstmpeg2encoptions.cc:
* ext/mpeg2enc/gstmpeg2encpicturereader.cc:
* ext/mpeg2enc/gstmpeg2encpicturereader.hh:
* ext/mpeg2enc/gstmpeg2encstreamwriter.cc:
* ext/mpeg2enc/gstmpeg2encstreamwriter.hh:
Streamline conditional code for evolving mjpegtools API,
optimize and fix/prevent crash in log handling, use
names/nicks for enums in the usual way andm inor updates
in code and properties/settings. Partially fixes bug #520329.
Original commit message from CVS:
This is a first attempt at a wrapper for the lib'ified mpeg2enc of
mjpegtools. Currently, there's a few release candidates for mjpegtools-1.6.2
available, but no stable version yet.
I've made 4 small subclasses to wrap input, output, options and generic
encoding model. The last .cc file is the GStreamer plugin element.
Note that it doesn't actually work yet, I'm doing something wrong with
header parsing and Andrew asked me to commit so he could help debugging
that. Apart from that, we should soon be able to make top-quality MPEG
encodes! :).
mpeg2enc licensing is tricky, btw, I don't even want to start discussing
that...
