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

[Danne]

You have to enable mlv_snd module. MLV_REC.tmp has nothing to do with this. Anyway, seems you have it working so let,s keep up the 10/12bit testing.

[MAG]

@MAG
With the crop_rec module I think it,s posible to record unstretched mv720 mode(not mv1920)

Also if previewing the MLV files with raw_twk enabled please test to go back a few files then forward a few files. Do this a couple of times and see if screen turns black?

Yes in playback, the screen turns black after couple of time. (raw_twk and mlv_play)

Also when I say record crop mode, I mean in ZOOM mode. The build I have doesn't have "crop_mode" module (2016Dec18.5D3113)

So, it's impossible to record fullframe 1080p without stretch ?

[Danne]

I think maximum is 38 fps mv1080. Also let,s try to stay on topic here. You can dig out a lot of info with 'search' regarding stretch/unstretch footage.
Thanks for verifying raw_twk issue

[aschille84]

6D: 10/12-bit with mlv_snd working in raw_rec and mlv_rec. Nice!

In cam preview with raw_twk working, but goes black when scrolling thru 3 clips or more.

Live view freezes on canon/ml greyscale without global draw preview, scrambled grey on ml greyscale w/global draw on.

latest @dfort build "magiclantern-raw_video_10bit_12bit.2016Dec18.6D116"

[Danne]

Live view freezes on canon/ml greyscale without global draw preview, scrambled grey on ml greyscale w/global draw on.

How do you mean? Does the camera freeze when previewing with grayscale?

[aschille84]

How do you mean? Does the camera freeze when previewing with grayscale?

On the 6D normal canon preview freezes in a still frame. I doesnt freeze on greyscale, its scrambled grey as earlier when global draw is on. So, limited preview options.

[Levas]

At this moment a bunch of camera have working live view while recording 10/12 bit (5D3, 60D, 600D, 650D, 700D and the EOS-M)
other ones have freezing live view while recording 10/12 bit video.

[honza123]

A brief summary of the test MLV-REC 10bit RAW on 600D:
RAW_twk - works
MLV_ snd - works
Most of the raw-videos converted with MLV_dump are badly decoded.

:-)

[Danne]

When using mlv_dump.
http://www.magiclantern.fm/forum/index.php?topic=5601.msg176263#msg176263

[DavidSh]

Any news on 5d3.123?

[budafilms]

@D

Can you update the first post with the latest results?

- what works at the moment
- tools for process on pc or/and mac at the moment

It's just a couple of lines.

Thank you.

[D_Odell]

Using 18dec build and the crop marks or actual pixels aren't shown in live view on 113 5D3. If I remembered correct the 4 Dec showed correct crop/actual pixels while recording. Anyone experiencing the same? Problem is that it's impossible to frame while rolling. Best, David

[dfort]

Using 18dec build and the crop marks or actual pixels aren't shown in live view on 113 5D3.

5D3.113 has the most amount of downloads by far so someone should be able to comment on that.

Just for fun, here are the download counts of the December 18 test builds. Checkmarks are for cameras that are working with CONFIG_EDMAC_RAW_SLURP:

5D3.113	-	28	√
7D.203	-	8
5D2.212	-	6
EOSM.202	-	6	√
550D.109	-	5
6D.116	-	5
600D.102	-	4	√
50D.109	-	3
60D.111	-	3	√
650D.104	-	3	√
700D.114	-	3	√
500D.111	-	1

Any news on 5d3.123?

That is a bit more challenging to build and I don't have a camera to check it out but here's a build for any 5D3.123 user who would like to check it out--please report your findings.

https://bitbucket.org/daniel_fort/magic-lantern/downloads/magiclantern-raw_video_10bit_12bit.2016Dec20.5D3123.zip

@D

Can you update the first post with the latest results?

@d started this topic on May 22, 2013, has only made 6 posts and hasn't been seen on the forum for over two years.

[MAG]

Using 18dec build and the crop marks or actual pixels aren't shown in live view on 113 5D3. If I remembered correct the 4 Dec showed correct crop/actual pixels while recording. Anyone experiencing the same? Problem is that it's impossible to frame while rolling. Best, David

I try the 18dec 5DIII there is no crop_rec and when I zoom record I don't have good liveview...

May be dfort do some test before adding crop_rec ?

[dfort]

May be dfort do some test before adding crop_rec ?

I'm doing test builds of just the raw_video_10bit_12bit branch for now. The crop_rec module is only working for the 5D3 and EOSM, is on a different branch and I don't want to introduce yet another variable until all possible cameras are working. If you want to experiment with crop_rec try merging branches--it really isn't that hard to compile and there are several tutorials in the General Development Discussion area of the forum.

[honza123]

10bit raw - video test /build 18dec 2016/

www.youtube.com/watch?v=XH3yVrSHVQQ

"magiclantern-raw_video_10bit_12bit.2016Dec18.600D102.zip"

:: EOS 600D ::
MLV_REC + MLV_SND, ISO 400, 1728x648, 23,98fps

Most of recorded videos are fine.
Some of them are bad decoded. Some of videos are without sound.

Original video file:
https://ulozto.cz/!JoQQdlZxLl9X/10bit-raw-video-test-build-18dec-2016-mp4

[Markus]

5d3 113 mlv + sound 10, 12 & 14 bit seams to be working for me as well.

 

Gonna try 123 later.

[vstrglv]

If you want to experiment with crop_rec try merging branches--it really isn't that hard to compile and there are several tutorials in the General Development Discussion area of the forum.

It is not easy. There are many conflicts when merging Unified into crop_rec branch.

[chmee]

ok, put 10 and 12bit into raw2cdng. if someone s still using this tool

[GutterPump]

ok, put 10 and 12bit into raw2cdng. if someone s still using this tool

Of course, im still using your soft as mlv viewer and extractor. Thanks for your update.

[budafilms]

Where is the module for for 5d3 1.1.3?

[Ali Oliya]

Why this 10bit/12bit build is not available for download in  nightly builds? (5d3 - 1.1.3)

[Walter Schulz]

Because it is still in development. There is a "main repository" containing code considered to be tested/evaluated/peer reviewed. New features will tested by whoever dares to do so (= not afraid taking additional risks) in so called "branches". If (and only if) a dev is convinced code has been verified it will make it into "main" and then you will find it in the nightlies.

If you want to test this one (and taking all the responsibilities) you may use downloads compiled by members or build your own development environment. There are some quite good tutorials by dfort working perfectly for beginners like me.

[honza123]

Test of 10bit RAW_REC with EOS 600D.
www.youtube.com/watch?v=WZ9unJonmOY
Build: "magiclantern-raw_video_10bit_12bit.2016Dec18.600D102.zip"
RAW_REC, ISO 400-800, 1728x972, shutter: 1/15s, 12fps (postprocess: RawTherapee, Virtualdub, Avisynth, Kdenlive)
Original video file: https://ulozto.cz/!SbnYaSK0n6gx/karvina-frystat-2016-avi

Danne: thank you for the advice ;-)

[Levas]

As seen some post before, eNnvi tried to make CONFIG_EDMAC_RAW_SLURP work on the 6d.
One thing is working, live view doesn't freeze anymore when recording 10/12 bit on the 6d 
However new problem now is, the recording gives scrambled/pink frames 

So we're halfway there...
Since live view works, the address for CONFIG_EDMAC_RAW_SLURP is probably right and looks like this in the 'raw.c' file:
#ifdef CONFIG_6D
// found at 0xFFCE513C (ram func)
#define DEFAULT_RAW_BUFFER MEM(0x76d6c + 0x2C)
#endif

Question is now, why do we end up with scrambled/pink frames. Are we not using a right free edmac channel in 'edmac-memcpy.c' ?
which is configured as follows:
#if defined(CONFIG_650D) || defined(CONFIG_700D) || defined(CONFIG_EOSM) || defined(CONFIG_6D)
uint32_t raw_write_chan = 0x12;
#endif

I'm not an expert in this, but I'm wondering why some camera addresses are written as 0xXX and for other camera's like the 5d3 for example as a plain normal number:

/* for other cameras, find a free channel with find_free_edmac_channels  */
#ifdef CONFIG_5D3
uint32_t raw_write_chan = 4;
#endif

I'm wondering if I could brick my camera when trying out a normal written number address for the 6d like:
#ifdef CONFIG_6D
uint32_t raw_write_chan = 8;
#endif

eNnvi mentions that the scrambled/pink frames problem could also be due to wrong edmac flag settings.
We tried both options for 6d, the first one gives pink frames, the second gives scrambled frames.
/* see wiki, register map, EDMAC what the flags mean. they are for setting up copy block size */
#if defined(CONFIG_650D) || defined(CONFIG_700D) || defined(CONFIG_EOSM) || defined(CONFIG_6D)
    uint32_t dmaFlags = 0x20000000;
#else
    uint32_t dmaFlags = 0x20001000;
#endif

So anybody got suggestions how to get this working, and is it safe to try out some different free edmac channels, or will it brick my camera when I pick the wrong one?