Well I didn't discriminate what stuff I migrated really, simply let git svn do its thing, for my purposes the only code I care about is in mpeg2enc/ really :) Regarding write access, I must say my familiarity with SVN is so low I'd be afraid to make a mess and never make use of it anyway, I would of course be more comfortable with a git repo but I still wouldn't be much help maintaining this project :)
Hey Andrew, thanks for dropping by :) MPEG-2 encoding is still used in broadcasting for backward compatibility reasons, and in this context CBR is very much a requirement, and a bitrate in the 15-20 Mbps range for HDTV is actually pretty typical as far as I know. As far as I've observed with my test samples avoiding reencoding in the second pass doesn't make a significant difference in terms of bitrate peaks, perhaps something doesn't scale right at higher bitrates as you suggest indeed, though from...
re hardcoded limit, there is one indeed but it's 16 : mjpeg_play/mpeg2enc/encoderparams.hh:#define MAX_WORKER_THREADS 16 Not that it really matters, because most of the encoding work is still done in a single thread anyway :)
Heya, thanks for following up, indeed I didn't realize that command line was encoding as MPEG-1, but the behaviour is the same with MPEG-2. I also observed marginal improvements in encoding time with the reduction switches, but nothing significant enough. I ended up exposing a "disable-encode-retries" property in the GStreamer wrapper: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1491/diffs?commit_id=93a54093ec821e9c46fd8cefcb3f06f54777b05e , it's probably a bit hacky...
Oh wow, awesome thanks, I did not expect anyone to review / merge this, thanks :) Unrelatedly, I have migrated the repo to git (https://gitlab.freedesktop.org/meh/mjpegtools), in case that's useful?
Expose API for user-specified PictureData
Systematic reencoding in second pass