Fix for pink frames

[a1ex]

Having some major problems with pink frames with 5D3 123 (also reported by pompeiisneaks), I took a closer look and I believe I've fixed them for good (at least on this camera).

So, besides the well-known pink frame problem (let's call it issue #1), 5D3 123 had a new kind of corruption: all frames were geometrically correct, but colors were scrambled (examples in the link from pompeiisneaks; let's call this one issue #2). I believe I've fixed both of them (but to be sure, it needs lots of testing).



How I've reproduced the issues:

- raw_rec grayscale preview: there was a flicker very similar to the pink frames (half of frame was good, the other half was shifted to the right). This was clearly issue #1. In crop mode, there was roughly a corrupted frame every 5 seconds.

- silent pictures in burst mode corrupted. This was mostly issue #2, but I've also got instances of #1. I've got corruption in roughly one out of 3 burst sequences in "best shots" mode. Downgraded to 1.1.3 to test the same code, all clean.

- silent pictures in slit-scan mode corrupted (clearly issue #2). Harder to reproduce (say one corrupted picture out of 20), but this gave a very clear hint about the source of the problem. Since in this mode I don't use any kind of EDMAC trickery (just plain memcpy), it was clear that issue #2 was from Canon's lv_save_raw code (which, if you remember, is just a debugging flag for LiveView, and it's not used in normal operation of the stock firmware - thus, it probably didn't get much testing coverage from Canon).
 
The behavior from raw_rec preview confirmed the hint from silent pictures (while raw recorder was idle, there was no EDMAC trickery either - the preview was displayed from Canon's buffer). So... the corruption was there in Canon's raw buffer, and was not caused by our EDMAC calls. I've smelled this a while ago here: http://www.magiclantern.fm/forum/index.php?topic=6567.0

How I've fixed it:

So, I took the edmac_memcpy routine, remembered a hint from g3gg0's first lv_rec implementation where he said the raw buffer can be extracted by attaching a write EDMAC channel to connection #0, and implemented just that.

Had a small surprise to notice that using EDMAC channel #18 (the one used by Canon's lv_save_raw) with my code resulted in issue #2 present (exactly the same corruption). I now use EDMAC channel #4 and it seems fine at first sight. Luckily, issue #1 seems completely gone (with both channels).

Result: a new raw backend, codenamed CONFIG_EDMAC_RAW_SLURP, that no longer relies on Canon's lv_save_raw. So far, I've got no corrupted silent pics (out of a few hundred) and raw_rec's preview had zero flicker for several minutes (tried all 3 modes - 1080p, 720p and crop). I didn't record much, but so far it seems clean even with Magic Zoom enabled at 60fps. Of course, MZ didn't flicker at all and there were no corrupted frames.

Relevant changesets:

The fix itself:
https://bitbucket.org/chris_miller/magic-lantern/commits/0c5c1c5683dfa7e15dba3024b8fdf7c7fde89f6c

Preparing for the fix (apply in reverse order):
https://bitbucket.org/chris_miller/magic-lantern/commits/5ba68a12e0c6969286c3d21d269d7574b1aa294c
https://bitbucket.org/chris_miller/magic-lantern/commits/61424cefadc03affe647eeb51d786ac22a981469
https://bitbucket.org/chris_miller/magic-lantern/commits/00647042c11a8f764b0c91ce7e825ee27e3e0f0b

Notes:
- I had to hardcode the raw resolutions in all video modes. Fortunately, on 5D3 there are only 3 of them.
- The raw buffer is now allocated by ML. I actually see this as an advantage, because the memory backend does some sanity checks. Sure, right now you lose a few MB of RAM, but you can always recover the old buffer (hopefully allocated by Canon code, but unused) and have it managed by the memory backend. Nanomad knows what I'm talking about.
- I've only tried it on 5D3 123 raw_rec. Trying on 113 is straightforward. To port on other camera, you need to find another free write channel (find_free_edmac_channels is there to help you with that) and hardcode the resolution (must be exact, copy it from Debug->EDMAC and don't forget to add 1 to height).
- There were no changes in the raw recorder code, so I expect mlv_rec to work out of the box.
- TODO: ensure thread safety in raw.c, maybe try some other EDMAC channels, and if this approach proves rock solid, I hope to replace the old code completely.

May the pink frames be gone

P.S. If you remember this animation, now it should be a lot less likely to drop useful data (even on full CPU load).

[dmilligan]

might this also provide a workaround for lv_save_raw not working on the 1100D?

[a1ex]

Worth trying.

[1%]

How did it affect speed... I remember trying different channels on 50D/6D/7D and picking the fastest ones.. I guess easiest way to see will be if MZ flickers or not.

[a1ex]

Benchmarks welcome (didn't do any). MZ doesn't flicker (but I don't remember it flickering on 5D3, not even at 60fps).

edit: did a quick test in crop mode, 2240x954, 30fps, hacked previews, both are running around 99-102 MB/s.

[nanomad]

It should help the 1100D to get raw LV hopefully as this won't fire up any of the Canon debug stuff. Raw recording not so much I suppose.

[pompeiisneaks]

I tested this out, and not getting pink frames so far, but I do seem to get every other recording to say "Invalid RAW" quickly so I can't play them back.  This is with regular RAW, for some reason the mlv_rec module is failing to build with:

Code: [Select]

[ GCC      ]   mlv_dump
mlv_dump.c: In function ‘lua_call_va’:
mlv_dump.c:64: warning: unused variable ‘verbose’
mlv_dump.c:63: warning: unused variable ‘nres’
mlv_dump.c:63: warning: unused variable ‘narg’
In file included from ../lv_rec/lv_rec.h:24,
                 from mlv_dump.c:305:
../../src/raw.h: At top level:
../../src/raw.h:185: warning: declaration does not declare anything
../../src/raw.h:193: warning: declaration does not declare anything
mlv_dump.c: In function ‘main’:
mlv_dump.c:2027: error: ‘struct raw_info’ has no member named ‘active_area’
mlv_dump.c:2028: error: ‘struct raw_info’ has no member named ‘active_area’
mlv_dump.c:2029: error: ‘struct raw_info’ has no member named ‘jpeg’
mlv_dump.c:2030: error: ‘struct raw_info’ has no member named ‘jpeg’
mlv_dump.c:2036: error: ‘struct raw_info’ has no member named ‘active_area’
mlv_dump.c:2037: error: ‘struct raw_info’ has no member named ‘active_area’
mlv_dump.c:2038: error: ‘struct raw_info’ has no member named ‘jpeg’
mlv_dump.c:2039: error: ‘struct raw_info’ has no member named ‘jpeg’
mlv_dump.c:2557: error: ‘struct raw_info’ has no member named ‘active_area’
mlv_dump.c:2558: error: ‘struct raw_info’ has no member named ‘active_area’
mlv_dump.c:2559: error: ‘struct raw_info’ has no member named ‘active_area’
mlv_dump.c:2560: error: ‘struct raw_info’ has no member named ‘active_area’
make: *** [mlv_dump] Error 1


[a1ex]

Never got "Invalid RAW" (tried around 50 clips). How does this message look like?

[1%]

How do the edmacs go now? 18 is 0x11 so is it hex->dec +1?

Also which edmac to copy the sizes from? 0x18? 0x21?

[pompeiisneaks]

It happens fast, but it seems like when I press the play button to view the file it just is a black screen with white text, I just got it again:

Invalid Raw:
A:/pathtocard/file

but then I just tested and if I exit and reload then I can view the sequence just fine.  Odd.

Oh I just got the screen to stay:

Invalid RAW:
A:/DCIM/100EOS5D/M11-1226.RAW

I have 'no image' showing up too, so maybe there's some other corrupt file on the card I need to remove and it is unrelated.  I'm guessing it is safe to ignore for now.

~Phil

[a1ex]

Commited it to main tree: https://bitbucket.org/hudson/magic-lantern/pull-request/382/fix-for-pink-frames

Also ported on 60D. No more pink frames in grayscale preview at 2.5K. This commit should help you see what exactly you need to port it on your camera: https://bitbucket.org/hudson/magic-lantern/commits/a32489b6c009

Nanomad confirmed it working on 1100D.

[1%]

I did all that but I'm getting garbage pics... edmac 0 is only 1440x200 or something like that... the others keep repeating resolutions that change and seem to correspond to something close to what the old pics were. Some are odd, one is even around edm 10 (according to edmac printout in debug).

I'm using free edmac channel 6... should I write them the same as the old channels were... ie 0x18, 0x6, etc? Any better way to verify the res?

[a1ex]

It's not edmac #0, it's connection #0. To copy the resolution, enable raw with the old method, then look at RAW_LV_EDMAC. Width: convert it from bytes to pixels. Height: add 1 to the value from edmac.

Channel: on 5D3 I've got 4, 8 and 15 free from the test routine, but only 4 worked well.

[pilgrim]

@ Alex, I admire your instinct... you sniff the problem on the right place  as usual.
@ 1% , nanomad, dmiligan, pompeiisneaks... I am happy that you understand well also and directly implement on the camera which correspond with your development.

I don't know the programming of ML, so I always wonder with all of your works. Today I took some pictures with dual-iso. I got some pink frames but much less than before, and also because with ambiance lots of over-expose. I use the night build Feb. 10,  2014.
Once again, thank you very much for the good news and your nice collaboration.

[a1ex]

Dual ISO has nothing to do with raw video pink frames.

Solved memory conflicts by reusing Canon's raw buffer address. This means one more thing to hardcode though, but the code is much simpler now.

[nanomad]

1100D is recording raw video. 640p @ 30 fps, but it's raw video nonetheless, right? 

And it even plays back the video too. This is a lesson for me: never throw the towel

[1%]

Hehe, I'm still getting garbage... even though my silent pics are the same dimensions now.. I guess I'll shamem the Raw_LV_Edmac the old way (exact dimensions) and try to xref the new memory addresses.

I did this: uint32_t raw_write_chan = 0x11;

free indexes on 6D: /* Write: 6 8 15 */

[a1ex]

You won't be able to read the edmac the old way because you have to call lv_save_raw for that. Simply hardcode the numbers returned by old EDMAC and should be fine.

The behavior of write channel is still a mystery. Why some of them work and others result in corrupted image? (or sometimes no image at all?) even if they seem unused in the EDMAC dialog?

[SteveScout]

Can we help testing? Will this be in the next nightly build or do we have to download the fixed files individually from your bitbucket link and copy them onto our ML card?

thanks for looking into this!!

[a1ex]

5D2 is odd: before it didn't have pink frames, but with the new method it has.

It does have some other kind of corrupted frames, like these: http://www.magiclantern.fm/forum/index.php?topic=5763 .

What's interesting is that poking 0xc0f08114 (raw type register aka KindOfCraw) was essential to get a continuous raw feed.

[a1ex]

To test it, you should first be able to reproduce the issue with current nightly builds. Let me know if you are (and what camera you are using).

Right now, the fix is available only as source code, for 5D3 (both firmware versions) and 60D.

[1%]

The behavior of write channel is still a mystery. Why some of them work and others result in corrupted image? (or sometimes no image at all?) even if they seem unused in the EDMAC dialog?

Some of the edmacs I tried resulted in the LV slowing down to a crawl. I tried 6, 8, 0x11(w-edmac8) and 0x21 (edmac 15), 15. None give me a good image, height + w is copied. When I move the camera around I can kinda see images through what looks like the matrix in the B/W preview.

I'll have to try 50D and 7D and see if its better/faster/worse/nothing

[nanomad]

Are you sure the size is correct?

[1%]

Should be...

I did this before changing over:

Code: [Select]

/* Edmac Sizer */
uint32_t lv_raw_height = shamem_read(RAW_LV_EDMAC+4);
    uint32_t lv_raw_size = shamem_read(RAW_LV_EDMAC+8);
    int pitch = lv_raw_size & 0xFFFF;
    int width = pitch * 8 / 14;
    int height = MAX((lv_raw_height & 0xFFFF) + 1, ((lv_raw_size >> 16) & 0xFFFF) + 1);
    NotifyBox(5000, "H: %d, S: %d, W: %d", height, lv_raw_size, width);


Some mild success on 7D. I can record in 5x... but performance is much lower and there are MORE pink frames. I'm still looking for a memory address that shows a raw buffer there too.... also same raw address in 1x is black while in 5x is a good raw image.


Also interesting: 6D addy 0x76D48 shows the same address as a shamem from the raw LV edmac + 0x40000000... subtracting it didn't help, same matrix style image.

[andy kh]

i test today's nightly on 550D. there are pink frames.