Repository navigation
Conversation
QVideoFrame::toImage() hardcodes BT.601 limited range for every YUV format and
ignores the color space and range the frame declares. Full range sources (all
MJPEG, and many capture cards' YUYV) come out over-saturated, which pushes
color-ratio detectors just outside tolerance while the video looks fine.
- Add Kernels/YUVConversion: YUYV, UYVY, YUV420P, YV12, NV12, NV21 -> RGB32
(scalar / SSE4.1 / AVX2, runtime dispatch). ~15x faster than toImage().
- SnapshotManager uses it, falling back to toImage() for other formats.
- New Video Pipeline options:
- FORCE_FULL_COLOR_RANGE (default off): for devices that mislabel full range
YUV as limited (V4L2 defaults to "limited" when the device says nothing).
- USE_QT_YUV_CONVERSION (default off): escape hatch back to Qt's converter.
|
Can you add tests for this? You can look at the other kernel modules like For this case, you'll probably need to have a few "golden" input/output cases to test against. So you won't be able to use the round-trip method or the "compare against Default" method that many of the other tests do for simplicity. |
|
|
||
|
|
||
|
|
||
| ImageRGB32 frame_to_ImageRGB32(const QVideoFrame& frame, bool force_full_range){ |
There was a problem hiding this comment.
Is this function mostly duplicating Qt's implementation with YUYV replaced with the new implementation?
I'd rather you just check for YUYV. If not that, then call Qt's implementation. That we we pick up Qt's changes in future Qt updates.
There was a problem hiding this comment.
This PR would change how my macOS decodes images and makes it 2x slower as it has no macOS accelerated implementation
Qt's
toImage()always decodes YUV as limited range, so a full-range source would come out over-saturated and color-based detectors miss even though the video looks fine.This PR adds in our own YUV->RGB conversion kernel (YUYV, UYVY, YUV420P, YV12, NV12, NV21) with SSE4.1 and AVX2 versions as well. It will use the declared color range based on my own testing is about 15x faster than Qt's kernel.
It does add a few new settings, like Force Full Color Range, for cards that mislabel full range as limited, and "Use Qt's YUV Conversion" if something goes terrribly wrong.
Windows should be unaffected because it receives RGB frames already.
This will conflict with my other PR for the Linux work.