Repository navigation
[Bug]: iPhone MOV import renders yellow/green corrupted frames in macOS editor preview #1390
Description
Search existing issues
- I have searched the existing issues
Describe the bug
Importing a video recorded with an iPhone (reported source container: MOV) into OpenScreen on macOS produces severely corrupted video in the editor preview.
The preview is filled with yellow/green vertical bands, blocky noise, and fragments of the original image. This is severe image corruption, rather than simply incorrect HDR brightness or saturation. The surrounding editor UI and frame/background render normally.
Expected behavior
The imported video should display recognizable, correctly oriented frames. If a codec or pixel format is unsupported, please show a clear error or offer conversion rather than render corrupted frames.
To Reproduce
- Record a video using the iPhone Camera app.
- Transfer the original MOV file to the Mac.
- Import the file into OpenScreen and open it in the editor.
- Play or seek in the timeline and observe the corrupted preview.
The exact recording settings and a shareable minimal source sample have not yet been collected, so these steps describe the affected workflow rather than a confirmed reproduction with every iPhone MOV file.
Screenshots
Portrait preview at approximately 00:03.3 of a 00:24.2 clip. Editor canvas is 1110 × 1920 (not confirmed source dimensions). The border and editor UI render normally.
OS
macOS
OS Version
26.6.2 (read from the reporting machine at filing time)
Other OS
No response
Browser
None
Browser Version
No response
Other Browser
No response
Device Type
None
Other Device
No response
Additional context
- OpenScreen: 2.1.1 (installed app version, read at filing time).
- Desktop application; no external browser involved in video import.
- The exact iPhone model, codec profile, bit depth, HDR metadata, frame rate, and rotation metadata of this particular MOV have not yet been inspected.
- HEVC / 10-bit / HDR / Dolby Vision handling is a possible investigation direction, not a confirmed root cause. Pixel format/plane stride handling and preview compositing may also be relevant.
- Related: macOS: is software decode still the right pick for 10-bit and HEVC? (4K now measured — it is) #584 and perf(export): measure 10-bit macOS decode before touching the software-decode predicate #676 concern macOS HEVC/10-bit decode behavior; macOS: the preview's decode backend has never been measured #585 concerns preview decode behavior. They do not appear to describe this specific visual corruption.
- Export behavior has not been tested.
- Re-encoding to H.264 8-bit SDR with proper HDR-to-SDR tone mapping has been proposed, but has not been validated as a workaround.
- No original video, private filesystem paths, project files, or diagnostic logs are included.
Activity
EtienneLescot commentedon Oct 25, 2026
Thanks for the detailed report, @Jpss1230!
To reproduce it we need to know exactly what's in that file. Could you share:
ffprobe -v error -show_streams -select_streams v:0 yourfile.MOV(codec, pixel format, color transfer, rotation)With that we can build a matching test file and track it down.
Jpss1230 commentedon Oct 25, 2026
Thanks for following up, @EtienneLescot. Here is the additional information.
Confirmed recording details
Video stream details from local inspection of the affected MOV
The following is a text summary from the bundled FFmpeg's input inspection, rather than the exact requested
ffprobe -show_streamsoutput:The file contains 10-bit HDR/HLG and Dolby Vision metadata as shown above. The exact Camera settings UI selections for High Efficiency / Most Compatible and the HDR Video toggle have not been independently confirmed, so I am not claiming specific toggle settings.
MP4 export
An MP4 export from OpenScreen has not yet been tested, so I cannot confirm whether the corruption also affects exported output.
Sample
I am sharing text diagnostics only and will not upload the source video or a video sample. I hope the stream details above help you construct a matching test file.
EtienneLescot commentedon Oct 28, 2026
Thanks for the detailed ffprobe output, it was enough to reproduce this on a Mac with a similar 10-bit HEVC HLG file. The 10-bit frames were being read as 8-bit, which gives exactly those stripes. A fix is up in #1408.
fix(compositor): read 10-bit VideoToolbox frames as 16-bit planes on …
EtienneLescot commentedon Oct 29, 2026
The fix (#1408) is now merged into main, so 10-bit HEVC videos from the iPhone should render correctly in the macOS editor. It will ship in the next release. Thanks again @Jpss1230 for the detailed report, and feel free to reopen if you still see the stripes once it's out.