"Color Option" set to blue-grey. Now all colors are complete in <rec>, other b/w in <play>.
CO set to khaki, the (<rec>) colors are same as before.
OK, I think we have an explanation. Good news, it doesn't look like bit rot, firmware dump is not needed. Bad news: It makes our lives complicated.
The normal vid_get_bitmap_active_palette logic is only valid for the default color scheme (orange). When a different color scheme is used, the location in palette_buffer is offset by the number of the color scheme. This logic appears in ixus240 102a FUN_ff2ddd74 (ixus140 equivalent is FUN_ff20f904)
That's why in
post 295, caefix's rmem -i32 0x194b88 shows palette_buffer[0] being NULL, and palette_buffer[1] having a value, while koshy's (set to orange), has a a value in palette_buffer[0].
This also explains why playback is 16 rather than 4, because there needs to be space for each color option. This may provide a way of detecting the affected firmwares.
We could use get_parameter_data(0x1a,1) in vid_get_bitmap_active_palette replicate this, but it's not clear the current CHDK custom entries will be appropriate in different Canon palettes. I'm also not sure we want to call get_parameter_data so often.
It seems like there should be a variable somewhere that has the offset already applied or points to the actual current palette, but I haven't seen one.
Making vid_get_bitmap_active_palette and load_custom_colors handle NULLs correctly will at least avoid the memory corruption, and people affected may complain that the colors are messed up.
All cameras that offer this color option will need to a fix. I'm not sure how many there are, none of my cams have it, but the firmware code still checks the flash param.