Prepared upstream submissions#
Nothing here has been posted. Do not post anything without the owner saying so.
../upstreamable-patches.md is the register: every local third-party change,
graded, with the message to send where one is ready. This directory holds the
artefacts that are too big to inline there. The Windows lane’s register is
../upstream-windows-patches.md; its two
issue drafts below live here too.
Contents#
file |
what it is |
|---|---|
|
upstream OpenCV commit, |
|
upstream OpenCV commit, |
|
Windows lane, unrelated to the Linux register |
|
Windows lane, the container boot hang (issue draft for microsoft/Windows-Containers) |
Both OpenCV patches are the original upstream commits with their authorship
intact, fetched from github.com/opencv/opencv. They are here because the
OpenCV submission is a port to 5.x, not a fix of our own: send these. Our own
002-ffmpeg8-avcodec-config-api.patch is gone since 2026-09-02; the Linux lane
applies these same two commits, byte for byte, as
linux/scripts/patches/opencv/002a-upstream-ffmpeg-pix_fmts-removal.patch and
002b-upstream-ffmpeg-supported-config-framerates.patch.
Verified 2026-09-02 against opencv/5.x:
both apply with no conflicts
after applying them our own patch no longer applies at all, i.e. upstream covers the same code
the
c->pix_fmtsandcodec->supported_frameratesuses that remain in the ported files all sit in the pre-FFmpeg-8#elsebranch, so the coverage is complete
Reproducing that check#
mkdir -p /tmp/cvport/modules/videoio/src && cd /tmp/cvport
for f in cap_ffmpeg_hw.hpp cap_ffmpeg_impl.hpp; do
curl -fsSL "https://raw.githubusercontent.com/opencv/opencv/5.x/modules/videoio/src/$f" \
-o "modules/videoio/src/$f"
done
git init -q . && git add -A && git commit -qm base
git apply --check <repo>/docs/upstream/patches/opencv-700cd32ffd.patch
git apply --check <repo>/docs/upstream/patches/opencv-83ed22ca28.patch