forked from happycube/ld-decode
-
Notifications
You must be signed in to change notification settings - Fork 85
Open
Labels
bugSomething isn't workingSomething isn't working
Description
Checklist
- I have searched the issues page for any duplicate issues open or closed and confirmed that this bug has not been reported before.
- I have tested the issue with the current build.
- I have attached log files, uploaded sample data, and commands used so that the issue can be easily reproduced by the developers.
Bug Description
When decoding a recording where the color burst was turned off at the source (TV station broadcasting the program), the otherwise black and white picture has spurious color noise overlaid.
Steps to Reproduce
- Download the RF sample here: https://drive.google.com/drive/folders/1fPjBYw_9C8Hc7EyjheOYf-F19lajUVGy?usp=drive_link
- Decode the sample with this command
decode.py vhs --threads 3 --tf vhs --ts SP -f 40 --ntsc --ire0_adjust zaroff-missing_color_burst-NTSC-SP-vhs-rf-40msps-u8.flac missing_color_burst_sample - Open the resulting tbc in ld-analyse. The first few seconds are a normal color video, the remainder is a black and white program with spurious color noise
Expected Behaviour
When the original content of the recording is missing the color burst, the video should decode in black and white.
Actual Behaviour
When the original content of the recording is missing the color burst, the video decodes with spurious color overlaying the black and white picture.
Environment
- Decode version: 0.3.5.2.dev1
- Operating System: macOS Sequoia 15.5
- Hardware Used: M1 Max
Additional Information
Decoded frame showing spurious color on a black and white video that originally had the color burst turned off

How the above frame should look when decoded without the color burst

Is it related to tbc-video-export?
No
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working