When displaying NV12 on our 18bit posing like 24bit 3.5" 6.xMHz panel, some pixels will have widly off colours.
The "frontend" (Scaler/Colour conversion engine) is responsible for converting from NV12 to RGB, which is then taken in by the Backend (the compositing display engine/pixel serializer), which is then taken by the TCON (timing controller, VGA speak is CRTC).
Some colours clip over, or have a byte not come properly. It is not possible to scale the issue up, or to move the coordinates to pinpoint the issue, as the issue then shifts, or even disappears altogether, and the wrong pixels do not scale up. This rules out several things, and points to a timing (between frontend and backend), caching (before frontend) or scaling phase issue (a setting in the frontend).
This needs some serious investigation.
A tool to display a single nv12 image on the lcd, was created, and to show the issue more clearly. Part of the cedarx2 h264 encoder userspace codebase.
When displaying NV12 on our 18bit posing like 24bit 3.5" 6.xMHz panel, some pixels will have widly off colours.
The "frontend" (Scaler/Colour conversion engine) is responsible for converting from NV12 to RGB, which is then taken in by the Backend (the compositing display engine/pixel serializer), which is then taken by the TCON (timing controller, VGA speak is CRTC).
Some colours clip over, or have a byte not come properly. It is not possible to scale the issue up, or to move the coordinates to pinpoint the issue, as the issue then shifts, or even disappears altogether, and the wrong pixels do not scale up. This rules out several things, and points to a timing (between frontend and backend), caching (before frontend) or scaling phase issue (a setting in the frontend).
This needs some serious investigation.
A tool to display a single nv12 image on the lcd, was created, and to show the issue more clearly. Part of the cedarx2 h264 encoder userspace codebase.