12-bit (and 10-bit) RAW video development discussion

[dfort]

Darn it.

Oh well, this is a work in progress. Any hints would be greatly appreciated.

[EDIT] This is what it is looking like on the 7D:

mv1080 mode 1736x976 10-bit


zoom mode 1920x1080 10-bit


Changing the video mode or resolution seems to garble it up. Maybe this has to do with the buffer addresses changing on Digic IV cameras that use LVState?

[dfort]

Posted allocate-raw-lv-buffer builds on my Bitbucket downloads page. It will probably be easier if we can make sure it is working on these before trying it with 10bit/12bit.

@masc - I reduced the RAW_LV_BUFFER_ALLOC_SIZE on the 5D2 so give it another try.

Here's what I'm doing if anyone wants to follow along.

https://bitbucket.org/daniel_fort/magic-lantern/pull-requests/15/searching-for-config_edmac_raw_slurp-on/diff

Click on the Commits tab to see the latest changes. If I remember to do it, I'll make the builds before committing the changes so you can open the autoexec.bin file in a text editor and read the latest news:

Code: [Select]

Magic Lantern Nightly.2017Dec06.5D2212
Camera   : 5D2
Firmware : 212
Changeset: c039449005d2+ (allocate-raw-lv-buffer-wip) tip
Built on : 2017-12-06 20:57:03 by rosiefort@RosieFoComputer

diff -r c039449005d2 src/raw.c
--- a/src/raw.c Wed Dec 06 12:45:04 2017 -0800
+++ b/src/raw.c Wed Dec 06 12:57:03 2017 -0800
@@ -120,7 +120,7 @@
 #define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0x1000)
 #endif
 
-#ifdef CONFIG_5D2
+#ifdef CONFIG_5D2 // keep working on this until it works!
 #define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0x2000)
 #endif


[a1ex]

In fact if you switch over to another mode then back to mv1080, it stops working.

Does it help if you start the camera in that other mode, rather than switching to it?

If yes (very likely IMO), the SRM buffer may have to be freed and reallocated again when the video mode changes (because Canon's memory layout changes). Disabling raw video before switching to the new video mode, and re-enabling it afterwards, should do the trick. On crop_rec_4k, mlv_lite does something about this, but the raw backend doesn't.

For 5D2 - I also had trouble with it and could not figure out why.

[masc]

Tried out again with latest allocate version. I did not change the mode (3x / 10x zoom). Switched on, LV enabled, record, stop. While recording, picture on screen is not refreshed.

5D2, 1856x1044, 25fps.

[ilia3101]

This is soo exciting!!!! Hoping 5D2 isn't impossible to do, though it might be as a1ex had difficulties.

@dfort Why change the buffer alloc size to be smaller, how could that random of a change help?

[dfort]

I think we're close on the 5D2. Let's see what happens when we shrink the RAW_LV_BUFFER_ALLOC_SIZE even more. The 5D2 has a huge SRM_BUFFER_SIZE and maybe the overhead is a percentage of the size instead of a fixed amount that can be used on all cameras. Just a guess. I kept changing it until it worked on the 7D.

New build posted. This time you should see this in autoexec.bin:

Code: [Select]

Magic Lantern Nightly.2017Dec06.5D2212
Camera   : 5D2
Firmware : 212
Changeset: c039449005d2+ (allocate-raw-lv-buffer-wip) tip
Built on : 2017-12-06 21:37:06 by rosiefort@RosieFoComputer

diff -r c039449005d2 src/raw.c
--- a/src/raw.c Wed Dec 06 12:45:04 2017 -0800
+++ b/src/raw.c Wed Dec 06 13:37:06 2017 -0800
@@ -121,7 +121,7 @@
 #endif
 
 #ifdef CONFIG_5D2
-#define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0x2000)
+#define RAW_LV_BUFFER_ALLOC_SIZE (SRM_BUFFER_SIZE - 0x4000)
 #endif
 
 #ifdef CONFIG_50D

Once we get it working on allocate-raw-lv-buffer we'll try it on 10bit/12bit.

Does it help if you start the camera in that other mode, rather than switching to it?

Didn't work. The only thing that works consistently is deleting the SETTINGS directory. Sometimes switching to another mode works but most of the time it doesn't.

On crop_rec_4k, mlv_lite does something about this, but the raw backend doesn't.

Guess I could try using the mlv_lite module from the crop_rec_4k branch. After all, that's where we want to end up with this!

[ilia3101]

Tried out your new build, artifacts very similar to what masc had, only first frame intact.

Wow... Lots of memories came back with that old raw_rec module

Just a guess. I kept changing it until it worked on the 7D.

Really interesting. I might try a few different sizes myself then. Did you have to shrink it a lot on 7D for it to work? What's the minimum size it can go to? The amount needed to fit a whole (full-size)frame?

Does it help if you start the camera in that other mode, rather than switching to it?

I did it all in the same mode, but could the 5D2 possibly be switching modes by itself at the start? I remember it had some weird double startup procedure or something...

[dfort]

Really interesting. I might try a few different sizes myself then. Did you have to shrink it a lot on 7D for it to work? What's the minimum size it can go to? The amount needed to fit a whole (full-size)frame?

Start reading from here and you'll see how I got to the current code. Once you get allocate-raw-lv-buffer working apply it to this version of raw_video_10bit_12bit.

Great to have someone who can compile checking this stuff out. Please let us know if you find something that works.

[dfort]

@masc - Let's try one more time before calling it quits for the day. New allocate-raw-lv-buffer for the 5D2 uploaded.

[ilia3101]

Start reading from here and you'll see how I got to the current code. Once you get allocate-raw-lv-buffer working apply it to this version of raw_video_10bit_12bit.

Thanks a lot. I'll read through that, and see what I can do, starting with reducing buffer size.

Also tried the new build, didn't do it

[dfort]

Ok--I played around some more with the 10bit/12bit stuff and merged in the latest changes. It seems a bit more stable, at least in mv1080 mode. Updated all of those builds.

[dfort]

Just a thought. If you can compile ML and have one of the Digic IV cameras that we're trying to get working, try different values for this:

src/edmac-memcpy.c

Code: [Select]

#elif defined(LV_STATE)
uint32_t raw_write_chan = 0x10; /* DIGIC IV LVState cameras */
I tried everything from 0x0 through 0x20 (this is hex so the count goes from 0-F) so that's the first 32 possibilites. You might notice that there is some code to find free edmac channels but experimenting around I found that sometimes what isn't listed might work better. You'll know when it doesn't work. I only tried it in mv1080 mode so maybe you need to switch to a different channel depending on the video mode?

[OlRivrRat]

                     @DFort

           When You Say "Updated all of those builds" just Which "all of those builds" are You referring to & Where can the Updated Builds be found?

[Danne]

Check the downloads page:
http://www.magiclantern.fm/forum/index.php?topic=19336.msg194178#msg194178

[IDA_ML]

Dfort, you seem to have reached a very important milestone - normal 1728x972 MLV video is now working in both: the MLV and RAW-video modes at 10, 12 and 14 bits.  CONGRATULATIONS !!!

After playing with your latest built on my 7D for several hours last night, I would like to provide some feedback.

1) In the normal uncropped mode I get continuous recording with synchronous sound at the maximum 1728x972 resolution at 10, 12 and 14 bits.  Color preview works just fine, so does focusing and framing.  Framing is maintained also during recording which is extremely useful in practical video work.  In-camera playback works only for the 14-bit MLV files.  With 10 and 12 bits a black screen is observed during playback but the counter works and shows the actual number of recorded frames.  Maybe,a working RAW_TWK module could solve this playback issue at 10 and 12 bits.

2) A problem occurs at 5x magnification mode.  When the magnification button is pressed  the screen freezes and no further adjustmens or focusing are possible.  However, when in this condition, the recording button is pressed, actual recording takes place and in the MLV-video mode recording with synchronous sound is possible even at the highest resolution available (2496x1198).  The MLV file looks gorgeous, there are no corrupt frames and sound works perfectly!  There are no "hick-ups" either, those frame jumps that are so annoying in the 100D.  Unfortunately, the frozen screen makes framing and recomposing during recording impossible.  So, this wonderful 5x magnification mode is usable only for static camera shots on a tripod.  Here are some record times on a 16GB Transcend x1000 CF card:

     * 14-bit (2496x1198) resolution with sound at 24 fps - about 70-75 frames
     * 12-bit (2496x1198) resolution with sound at 24 fps - about 140-160 frames
     * 10-bit (2496x1198) resolution with sound at 24 fps - about 420-510 frames (fantastic !!!)

Interestingly, the number of frames differs at each shot, although a constant bitrate is used.  Typically, the first shot after camera is turned on is quite short (say 240 frames at 10 bits in the above resolution), then the second shot is quite long (say 500 frames)and the next shots vary between 420 and 500 shots, if one succeeds in getting out of the frozen-screen state without turning camera off, (see #4 below).

3) A second, more serious problem occurs when you want to get out of the 5x magnification mode to shoot the next clip.  The only way to do this is by turning the camera off, taking the battery out, putting it back in and restarting the camera twice.  Only then you are back in the normal uncropped mode where you can compose, focus, meter and prepare for the next shot.  One workaround is to first turn MLV-video off, use LifeView to compose your shot, meter and focus in the 5x magnification mode, then turn MLV-video on again and take your footage.  This you can do only once.  Then you again have to pull the battery out and restart twice to get out of the frozen-screen state. 

4) Sometimes, when you playback the last recorded clip, (even just with black screen), the camera will return to its normal state, so you don't have to pull the battery out but sometimes it works and sometimes it doesn't.  I was unable to reproduce the issue.  I also played with the different preview modes but this does not resolve the frozen screen problem either as this was the case with older builds when you could get a normal screen after switching between those preview modes.     

I hope this is helpful to those who haven't been able to test yet.

[dfort]

           When You Say "Updated all of those builds" just Which "all of those builds" are You referring to & Where can the Updated Builds be found?

I post test builds on my Bitbucket downloads page:

https://bitbucket.org/daniel_fort/magic-lantern/downloads/

Though I tend to update or clear them out without much fanfare.

@IDA_ML

Wow, thanks for the great feedback. Yeah, I've been doing a lot of battery pulling with this experiment.

a1ex suggested looking at mlv_lite from the crop_rec_4k branch because it handles special cases for 10bit/12bit. Apparently there are certain frame sizes that don't work with reduced bit rates. In any case, it might be easier to move the changes from the allocate-raw-lv-buffer branch to the crop_rec_4k branch rather than cherry pick code from mlv_lite.

I believe that I've got the addresses for lossless on the 7D but don't have it working just yet. Of course that's another topic.

[masc]

Hej, I played a bit around again with your latest version for 5D2. I have some news:
- 640x360, 25fps, 10bit -> OK!!!
- 960x540, 25fps, 10bit -> OK!!!
- 1280x720, 25fps, 10bit -> not OK
- 1600x900, 25fps, 10bit -> not OK
- 640x360, 25fps, 12bit -> OK!!!
- 960x540, 25fps, 12bit -> not OK
fps override:
- 1856x1044, 2.5fps, 10bit -> OK!!!
- 1856x1044, 20fps, 10bit -> OK!!!
- 1856x1044, 22fps, 10bit -> not OK
- the very first frame is always OK
- if the screen freezes while recording, the file was not OK. If the file was OK, I had a preview while recording.
Maybe that helps... 
Unfortunately I don't have installed the toolchain needed for compiling...

[ilia3101]

@dfort WOW!!!! 10 bit works on the 5D mark II !!!... pretty much. I just shot a 10 bit clip at 1880x1056 in MLV Lite. MLV App confirms: Bits / Pixel: 10

I found the main factor for making it work is having fps override enabled, even without changing the framerate. I'm sure knowing that could be useful.
And I agree with masc's findings, display frozen=fail, not frozen=successful clip.

Also have you uploaded the source of the 10-12bit builds that you posted? I'm not very good at navigating bitbucket so don't know where to find it.

[dfort]

Also have you uploaded the source of the 10-12bit builds that you posted? I'm not very good at navigating bitbucket so don't know where to find it.

Sure, the dummy pull request is here so you can see my changes:

https://bitbucket.org/daniel_fort/magic-lantern/pull-requests/16/10bit-12bit-for-lvstate-cameras/diff

If you just want to get my repository set to that branch right away simply:

Code: [Select]

hg clone -u raw_video_10bit_12bit_LVState-wip https://bitbucket.org/daniel_fort/magic-lantern
Assuming that you have Mercurial installed.

[EDIT] If you already have a magic-lantern directory and don't want to clobber it try this:

Code: [Select]

hg clone -u raw_video_10bit_12bit_LVState-wip https://bitbucket.org/daniel_fort/magic-lantern magic-lantern-dfort

[Andy600]

@dfort - Had a very quick look at your 50D 10/12bit build. It's promising!

10bit 1584x856 ok / 2000*1076 (crop) ok - continuous recording on a relatively slow 800x CF card 
12bit 1584x856 ok / 2000*1076 (crop) fails with some frame tearing and intermittent pink frames
14bit 1584x856 ok / 2000*1076 (crop) fails with some frame tearing and intermittent pink frames

all 25p


The allocate-raw-lv-buffer build produces corrupt images in crop and non-crop modes.

[ilia3101]

If you just want to get my repository set to that branch right away simply:

Code: [Select]

hg clone -u raw_video_10bit_12bit_LVState-wip https://bitbucket.org/daniel_fort/magic-lantern

Thanks a lot for that, it worked wondefully. 14 bit recording has issues and I was wrong about just having fps override enabled fixing things, the framerate also has to be changed a bit.

Is it still worth toying about with making RAW_LV_BUFFER_ALLOC_SIZE smaller? Could it help get rid of some of the issues like some settings not working or pink frames?

10 bit 5D2 1880x1248 frame:

Just a thought. If you can compile ML and have one of the Digic IV cameras that we're trying to get working, try different values for this:

src/edmac-memcpy.c

Code: [Select]

#elif defined(LV_STATE)
uint32_t raw_write_chan = 0x10; /* DIGIC IV LVState cameras */
I tried everything from 0x0 through 0x20 (this is hex so the count goes from 0-F) so that's the first 32 possibilites. You might notice that there is some code to find free edmac channels but experimenting around I found that sometimes what isn't listed might work better. You'll know when it doesn't work. I only tried it in mv1080 mode so maybe you need to switch to a different channel depending on the video mode?

Will try this also, hopefully with some good results. No risk of bricking or anything?

[Andy600]

Just a thought. If you can compile ML and have one of the Digic IV cameras that we're trying to get working, try different values for this:

src/edmac-memcpy.c

Code: [Select]

#elif defined(LV_STATE)
uint32_t raw_write_chan = 0x10; /* DIGIC IV LVState cameras */
I tried everything from 0x0 through 0x20 (this is hex so the count goes from 0-F) so that's the first 32 possibilites. You might notice that there is some code to find free edmac channels but experimenting around I found that sometimes what isn't listed might work better. You'll know when it doesn't work. I only tried it in mv1080 mode so maybe you need to switch to a different channel depending on the video mode?

Haven't used the 50D for ages and had to get back up to speed with compiling ML but there now

Are you saying to try all channels? I can't remember how to check for free edmac channels (hint anyone?) but surely it's better to discount edmac channels that are in use rather than compiling ml 32x or more?

Trying to get my head around the architecture - are corrupt frames like I'm getting with your 10/12bit build symptomatic of using a shared edmac channel?

[dfort]

Good to see Andy600 and Ilia3101 jumping in.

@a1ex found the SRM_BUFFER_SIZE for the 500D so it looks like all of the Digic IV that use LVState might be able to work with 10bit/12bit. Well maybe just hobble along at a few resolution settings for now.

500D build is up on my downloads page.

Now that there is some momentum on this how about some of you that have these old cameras and can compile ML start experimenting with it and see if you can get it working good enough to get it accepted into the Experiments builds?

Here's a dummy pull request so you can see what's been done so far:
https://bitbucket.org/daniel_fort/magic-lantern/pull-requests/16/10bit-12bit-for-lvstate-cameras/diff

If you want to grab my branch and play around with it, here's how you can do it without overwriting your local repository:

Code: [Select]

hg clone -u raw_video_10bit_12bit_LVState-wip https://bitbucket.org/daniel_fort/magic-lantern magic-lantern-dfort
@Andy600 - It makes sense that you should try only the free edmac channels. I remember running something a while back that would show which channels were free but then I found out that there were other channels that weren't reported that worked better so I just kept trying. I got to that 0x10 value fairly early in the process so and there are probably other channels to try out so that's a good place to experiment.

Here is the edmac screen on a 7D. It looks like 19-22 (0x13 - 0x16) might be open write channels but I'm not really sure about that. Note that what I'm using 0x10 is 16 decimal which is the channel that has that big write buffer. (Take this with a grain of salt.)



@Ilia3101 - I'm not sure if reducing the RAW_LV_BUFFER_ALLOC_SIZE any further helps. I found out on the 7D that using the full SRM_BUFFER_SIZE wouldn't work at all. a1ex suggested reducing it by 0x100 but I had to go all the way to 0x1000 for it to work. Again, that could probably use some more experimenting.

By the way, I keep trying to get this Digic IV 10bit/12bit stuff working in the crop_rec_4k branch but keep failing miserably. It would be great to get some help with that.

[Andy600]

The 50D seems stable using EDMAC 01 and 02 - and for some reason I decided to work backwards from 1F

Tested at 25p and maximum mlv-lite 50D frame resolutions for non-crop (1584*1056) and crop (2000*1076). I've had no pink or torn frame issues and filled a 32gb card with 10, 12 and 14bit raw video.

I've uploaded the EDMAC 01 build here if any 50D users want to try it (entirely at your own risk!! Usual rules apply - if it breaks your camera I can't help!).
Removed to avoid any confusion. Please download from @dfort's repo

[dfort]

Ha ha -- like the saying goes, everything you find is in the last place you look for it.

Following your lead I updated edmac-memcpy.c. Getting ready for the possibility of each camera using a different channel.

Code: [Select]

Magic Lantern Nightly.2017Dec08.50D109
Camera   : 50D
Firmware : 109
Changeset: 269205a6d2d5+ (raw_video_10bit_12bit_LVState-wip)
Built on : 2017-12-09 01:19:40 by rosiefort@RosieFoComputer

diff -r 269205a6d2d5 src/edmac-memcpy.c
--- a/src/edmac-memcpy.c Fri Dec 08 12:18:33 2017 -0800
+++ b/src/edmac-memcpy.c Fri Dec 08 17:19:40 2017 -0800
@@ -341,8 +341,16 @@
 uint32_t raw_write_chan = 0x4;  /* 0x12 gives corrupted frames on 1.2.3, http://www.magiclantern.fm/forum/index.php?topic=10443 */
 #elif defined(EVF_STATE)
 uint32_t raw_write_chan = 0x12; /* 60D and newer, including all DIGIC V */
-#elif defined(LV_STATE)
-uint32_t raw_write_chan = 0x10; /* DIGIC IV LVState cameras */
+#elif defined(CONFIG_7D)
+uint32_t raw_write_chan = 0x10;
+#elif defined(CONFIG_5D2)
+uint32_t raw_write_chan = 0x10;
+#elif defined(CONFIG_50D)
+uint32_t raw_write_chan = 0x01;
+#elif defined(CONFIG_500D)
+uint32_t raw_write_chan = 0x10;
+#elif defined(CONFIG_550D)
+uint32_t raw_write_chan = 0x10;
 #endif
 
 static void edmac_slurp_complete_cbr (void* ctx)

Also posted a new 50D build.