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

Started by d, May 22, 2013, 10:58:34 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.


Quote from: domo94 on March 08, 2019, 06:20:42 AM
Oh man, the stability and security of recording this camera is going to provide is amazing.  I may not need to sell after all...

Ha, I'd rather sell my entire photo gear but the 7D - never !!!  As far as high ISO performance is concerned, you should try AETTR to see what this beast is really up to.


Some days I feel like a king with the 7d, others not so much.

I'm still not sure how AETTR works just yet.
Care to explain?


Just activate it in the Expo menu, adjust it and set triggering to your liking in the sub menu and use it before you shoot a still or video.  It will automatically analyze your scene and expose it to the right without blowing up the highlights.  This will maximise the signal-to-noise ratio (SNR) in the shadows and provide a very clean image.  Works very well.


Darn it -- thought I was onto something that would work with the 500D/550D by using RscMgr memory but no such luck. Sorry for the false hope.

Not sure why 10/12-bit isn't working properly on these cameras yet. Seems to me that it should be possible.

Walter Schulz

Quote from: domo94 on March 08, 2019, 09:47:45 AM
I'm still not sure how AETTR works just yet.
Care to explain?

Tip: Follow the links in feature matrix and you will be directed to https://wiki.magiclantern.fm/ettr
Happy reading!


Quote from: dfort on March 08, 2019, 05:21:45 PM
Darn it -- thought I was onto something that would work with the 500D/550D by using RscMgr memory but no such luck. Sorry for the false hope.

Not sure why 10/12-bit isn't working properly on these cameras yet. Seems to me that it should be possible.

It seems to be at the same point that the 5D2 was at a few years ago - 10/12bit was working in 5x mode but not 1:1. I'm still not sure what the most stable version of 10/12 bit is for the 5d2 but maybe the progress there will provide a clue.


Quote from: jpegmasterjesse on March 08, 2019, 11:16:37 PM
I'm still not sure what the most stable version of 10/12 bit is for the 5d2 but maybe the progress there will provide a clue.
It been stable since Oct/2018 and it's the same code that I have in the 3k crop_rec for 5d2 , so yea it's stable 


Quote from: reddeercity on March 09, 2019, 04:37:39 AM
It been stable since Oct/2018...

Actually just a little before that date. This is the commit that got 10/12 bit working with 1080p on the 5D2. Before that it was the same on all Digic 4 which was that it worked in zoom mode but not in mv1080 or mv720 mode. aprofiti figured it out for the 50D and I was able to do it for the 7D with a lot of guidance from a1ex and some ugly hacks by merging in the RscMgr_memory branch so it isn't in the main repository just yet.

It should be possible to get 10/12 bit working on the 500D and 550D which are the remaining Digic 4 LV State cameras but so far nobody has cracked that code.


Big difference between "should work" and "working" sometimes, right? What seems to be the biggest hurdle do you think?


Here's a quick test with the 10bit 60fps raw on the Canon 7D at the latest 2.0.3 build.

Shot in 2.35:1 ratio at 59.94 with a 24mm pancake prime lens.


Colors still look amazing,

some aliasing as usually, chromatic aberration, but nothing that my VAF filter can't fix and tidy up. Mind you, I did NOT shoot with my VAF filter for this. I just ran outside for 5 minutes and did the recording thing.


Quote from: dfort on March 09, 2019, 06:40:13 AM
This is the commit that got 10/12 bit working with 1080p on the 5D2.

!! 1080p on the 5D2?  Did I miss something?  ??? Tried the build above but I'm only able to load 1856 x 1004 max at 10bit. This has always been the case for me. What modules / settings yields a straight 1080p @ 16:9 on the 5D2?


KB 1000x CF card
5D3 1.1.3
5D2 2.1.2



There is no Camera that supported by ML can do Real 1080p except 5D3 , and another camera like 5D2 and 700D the res is a little bit lower, but if you are shooting in x5 mode you can get real 1080p but in crop mode only not the full sensor size.

1080p means a little bit lower resolution in the other cameras except in 5D3 . This is technical AFAIK we can't do real 1080p in full sensor size and this is related to sensors read out and how many mega pixels we have in the sensor.

More accurate way to say what we mean in 1080p in other cameras is to use word "mv1080" as Canon call it maybe; this is the mode when selecting 1080p in Canon Menu and without x5 crop mode but not necessarily the res is exactly 1080p. (H.264 does up scaling to 1080p).



Wow. I get you – but that is confusing!  :P

IMHO a non-standard way of describing a well-known/agreed industry format can lead to lots of confusion. I would have thought most pros believe 1080p to mean 1920x1080. These days 16:9 is the 'mother' ratio from which all the others – 1:85, 2:35 etc, are derived. It's certainly taken years for me to become familiar with the slightly esoteric way in which formats are discussed within the ML family.  ;)

I'd say it could lead to disappointment (especially in new ML adopters) if formats ratios/dimensions are described as, say 1080p, when that is not actually what they deliver – compared to those same descriptions used within the wider cineog community.

On my 5D3 I'm happy to describe my 1920x1080p, 24fps, 16:9 as 1080p – and know that another non-ML user understands what that output means.

On my 5D2 – by my own logic – I'd feel more honest to describe its max 1856x1004, 24fps, 16:9 as 1004p – but it would certainly require some explaining to others; and it doesn't sound quite so impressive.

I'm not complaining – I'm full of praise and gratitude to the ML gods who gave all this to us. Just sharing my opinion – leading possibly to a discussion around a unified and meaningful output naming – understood by all.


5D3 1.1.3
5D2 2.1.2


Upscale to 1920x1080p. You can't see the difference.


@Danne. I do – and it still looks superb!  :D But that was not my point (see above).
5D3 1.1.3
5D2 2.1.2


Well, the commit I pointed out does say:

QuoteRaw backend: experimental method for overriding raw stream parameters in Canon firmware (CONFIG_EDMAC_RAW_PATCH)
Stubs for 5D2. Clean footage in 1080p30 10-bit!

Like Bilal said--technically, only the 5D3 can do 1920x1080 raw video using the entire sensor area (3x3 sampling). Other cameras, including the 5D2, can do 1920x1080 by cropping in and using 1x1 sampling (a.k.a. zoom mode). Also note that the 5D3 also does horizontal and vertical pixel binning so it is much less susceptible to aliasing and moiré when using 3x3 sampling.

What made the 5D2 such a revolutionary camera was being able to shoot video (albeit lossy compressed H.264 -- at 30fps when it first came out) on a large sensor so that the depth of field was very shallow compared to the relatively small sensors of the video cameras from that era.

Back on topic, I've got an experimental build that allows 10/12bit reduced bit depth on the 7D but can't figure out a way to get it working on the 500D and 550D. Checking out the experiments download page it looks like those are the only cameras not working with 10/12bit. Well, there isn't a build for the 100D but I know that camera works--it just hasn't been merged into the raw_video_10bit_12bit_LVState yet.


I'm getting a ton of inconsistency with new 7D 10/12/14 bit RAW build.

I get 2:30 of recording time at 60fps, 1600x408 - 2.35:1 aspect ratio, auto live view, 12 bit raw, (with and without) external monitor connected.

Same thing at 10 bit I get about 1:25.

Ironically 14 bit is the most stable, but no 60fps, but yes 24 fps. 2.35:1 ratio, even up to 16:9 at times.

I'm randomly skipping frames and sometimes RAW module will just start recording and skip a frame right away.

As I'm typing this, I'm getting full continuous 60fps raw at 10bit, same settings, but I chose 'HACKED' preview instead of auto preview.


Are you talking about magiclantern-crop_rec_4k_mlv_snd_experiments_waza57.2019Mar21.7D203? That one is the latest mega-merged experimental build. How is it compared to the prior couple of experimental builds that I posted? I'm just doing some quick tests on the 7D before posting.

In case you are on the magiclantern-raw_video_10bit_12bit_LVState build - make sure you are using mlv_rec and not mlv_lite. There have been issues with mlv_lite with Digic 4 LV State cameras on that branch.


Currently on LV State Feb 21. 2019

There was an updated build? I was not aware of that.

Let me upgrade and see.



Please try the March 02 version and see how it works for you.  Don't forget to report your findings!


Right, let's stay on topic and continue testing the 10/12bit development here. Those changes I made to get the 7D working resulted in a huge changeset so it probably won't make it into a pull request in this current state.


@a1ex - Found a problem with the 700D.115 10/12-bit RAW video build posted on the experiments downloads page. This is recording 10-bit video with mlv_lite but a crash with a similar log happens with mlv_rec. It also saved a COREDUMP.DAT file.

[2] raw_rec_task: NULL PTR (80c3e100,e1a00000)
pc=    c288 lr=    c288 stack=1abdd0+0x1000
e1a00000 e59ff014 e59ff014 e59ff014
e59ff014 e1a00000 e59ff010 e59ff010

Magic Lantern version : raw_video_10bit_12bit.2018Oct10.700D115
Mercurial changeset   : db4ee396f4a2 (raw_video_10bit_12bit_LVState) tip
Built on 2018-10-10 14:16:48 UTC by jenkins@nightly.
Free Memory  : 128K + 3254K

I know that I have used this branch before and didn't have that issue so I ran hg bisect and it came up with this:

The first bad revision is:
changeset:   17692:fc5e8aa04abe
branch:      raw_video_10bit_12bit_LVState
user:        alex@thinkpad
date:        Wed Sep 26 08:14:44 2018 +0200
summary:     mlv_rec: fix compilation

Don't see anything there specific to the 700D so maybe some other cameras are affected? Note that this came up while trying to get the 7D working on this branch in a way that won't break any of the other cameras. I'm almost there. Got it working and the EOSM seems to be fine with it. So far it is just the 700D though I haven't tried the 5D3 yet--crash looks kind of scary. Easy to test (if you dare) and see if your camera is affected because builds are posted for every camera except the 7D.

[EDIT] There's also a build for the 700D.114 on the downloads page. Is there a reason for that?


Ok, so far, I've been shooting at 1600 x 408 at the following settings with mlv_rec:

59.94 fps
2.35:1 ratio

Global Draw: Allow
Preview Options: HaCKeD
Status When: Icon

Card Warm Up: 128 MB (I have 128GB CF Card)
Use SRM Job Memory: On

- I believe I changed the SRM and Buffer Options after recording 60fps, so some may not be accurate -

My camera is slow upon startup after I removed the card and disconnected battery for a while. It's super delayed when I move through menus.

Sometimes, when I power off and then on, and I record, I get 'RAW DETECT ERROR' and I have to turn off module and turn it on again for it to work as such:
I first record raw and I skip frames at 2 seconds~
The second time it works fairly well, I believe I skip frames after a while, can't remember.

I also have 'load modules after crash'  enabled. - > *If I have this feature enabled, I think it should have some sort of check in the beginning to see if it crashed or not, if it did, have it purge a memory or something?*

It seems to be some sort of memory issue? It remembers the settings but it cannot function sometimes or properly.
IS IT possible to do a purge of cache or something upon start up? (I'm just jotting possible ideas down for my understanding of how this all works. I have no code experience this far.)
When I also go to make sure my settings are correct when I restart the raw record functionality on the video menu, the word at the bottom of the menu describing each option give a last recorded measure of the raw recording frame rate limit. When I skip frame and go to restart, I notice that the frames change every time. The way the values are measured seems to update every time.

I have a link showing the last recorded clips.

Some have corrupted frames. The subsequent clip has less every time.

The third clip has 1 corrupted frame.



Is there anyway to get Magic Zoom to work on an external monitor?


Quote from: dfort on March 24, 2019, 07:28:49 AM
raw_rec_task: NULL PTR

Posted a new set of builds, with what I think it might be the fix. I've temporarily merged the "old" (but "clean") raw_video_10bit_12bit branch with new-dryos-task-hooks (a change there might have fixed it; need to refresh my memory). Please report back, as I don't remember being able to reproduce this issue.

If that works, I know what I have to do - merge the qemu branch into mainline, then merge new-dryos-task-hooks. Then lua_fix, but that's not so much about video recording.

Then, I need to do some serious cleanup on the patch manager, as I still don't trust that code for mainline (besides breaking the 7D build, which is rather minor, as the master code is not used at all in regular builds).


Quote from: a1ex on March 24, 2019, 11:15:06 AM
If that works, I know what I have to do...

It works. Tested on the 700D and EOSM.

As long as you are merging, would it be possible to include RscMgr_memory in raw_video_10bit_12bit_LVState? That is working great on the 7D as I posted on Reply #1774 and doesn't seem to break the other cameras. On the 7D I did have to block the master from compiling:

# all::

Is this an acceptable temp workaround?

Quote from: domo94 on March 24, 2019, 09:48:48 AM
59.94 fps

I take it you have the Canon menu set for 1280/60fps? That is going to give you some heavy aliasing. If we can ever get the crop_rec module working on the 7D we should be able to do 60fps at 3x3 sampling which will improve the resolution. Well, getting lossless compression working would help too. Getting 10/12-bit working is just one of the steps needed on the 7D.