Messages

There 's only a windows version of MLV_dump available on the magic lantern downloads page:
https://builds.magiclantern.fm/utilities.html

Can somebody add newest version of MLV_dump for osX ?

Try out remapping hot pixels.
Google for it:
Hot pixel remapping canon
Did helped a lot for raw video on my canon 6d.
If I remember correct you need to remove the lens, place the bodycap on the camera and then perform a manualy sensor cleaning from the Canon menu.
It helps to heat up the sensor a little by using liveview on iso 6400 a few minutes, right before doing the manual sensor cleaning.

On iso 6400 there probably still will be soms (hot) pixel noise, which is easy removed by most raw editors. Like RawTherapee, it has a hot pixel remover function on the raw tab

Hybrid LV AF make this camera useless.

@Greg
You mean useless for raw video because of the focus pixels ?
I thought these could be removed with the right tools, or can't they ?

I have been drooling over ML for as long as it's existed

Better be sure to buy a camera that has ML support 

Magic lantern support (and future support) seem to be best for the 5d series cameras (5d2 and 5d3), apparently biggest user base.

But 700D seems like a good choice too.
650D has probably about the same functionality, so could opt for that one too.

If you want to experiment with video, don't go lower/older then the canon 650D, the 600D has slower card writing speeds, also the 60D has slow writing speeds.

About the movie recording not working with wifi enabled.

I'm not sure if it is true but it makes sense to me, but I remember someone mentioning here on the forum that this feature probably doesn't work because of a shared DMA channel between WI-FI and video recording hardware.
So only one of them can be used at the same time,  which means the hardware is simply holding the feature back and not the firmware/software.

But I do wonder if it is possible to enable somehow video recording through wi-fi, by after the start signal, the camera shuts down the wi-fi connection and goes recording and the enables wi-fi after recording again.
But that sounds like a lot of work to implement, which I have no knowledge about 

@Geggo

so MLV averaging produces the correct format, right?

Yes, the resulting average MLV has the right format, the average MLV is 12 bit, when input MLV is 12 bit.

Only thing new to me was that when extracting dng's, it gives 14 bit dng's no matter what the input is, 10/12 or 14 bit.
I was used to a MLV_dump which gave dng's in the same bit depth as the recording was.

@Geggo

MLV conversion to dng's gives 14bit dng's even with 12 bit mlv's.
So 12 bit MLV gives 14 bit dng frames
Doesn't matter if average is used or not, always end up with 14 bit dng's

The MLV_dump build I used before, 20 November 2016 build, gave 12 bit dng's or 10 bit or 14 bit, depending whatever bit depth the mlv file was recorded.

@Geggo
I did use the same mlv_dump as in your link.
The build from 25th december for osx

When I use that build on 12 bit mlv's, I'll get 14 bit dng's 
Which is nice, as in you can view them normal in finder, but the downside is that file size is also increased 

[workingDir=`dirname "$0"`cd "${workingDir}"sudo mv ./mlv_dump.osx /usr/bin/mlv_dumpsudo chmod +x /usr/bin/mlv_dumpfor FILE in `ls -A1 *.MLV *.mlv 2>/dev/null`; do BASE=`echo $FILE | cut -d "." -f1`; mkdir $BASE; mv ./"$BASE".M* ./$BASE cd ./$BASE /usr/bin/mlv_dump --no-fixcp --no-stripes -o ${BASE}_frame_ $FILE -a cd ..done]

I'm using an old script which was once available on magic lantern, made some alterations for averaging.
Input file is 12 bit mlv, output file is a single frame 14 bit mlv

workingDir=`dirname "$0"`
cd "${workingDir}"

sudo mv ./mlv_dump.osx /usr/bin/mlv_dump
sudo chmod +x /usr/bin/mlv_dump

for FILE in `ls -A1 *.MLV *.mlv 2>/dev/null`; do
    BASE=`echo $FILE | cut -d "." -f1`;
    mkdir $BASE;
    mv ./"$BASE".M* ./$BASE
    cd ./$BASE
    /usr/bin/mlv_dump --no-fixcp --no-stripes -o ${BASE}_frame_ $FILE -a
    cd ..
done

So I've downloaded the 25th december 2016 version of mlv_dump and now I get normal dark dark frames from averaging a mlv file.
And I noticed the differince in file size, this version of MLV dump creates 14 bit files, where the older mlv_dump created 12 or 10 bit files.
Is this for compatibility reasons or are there other advantages that the output files are converted to 14 bit ?

Sounds like I'm doing something wrong here...
I'll try the latest mlv_dump, is there a standard download location for the newest mlv_dump?

I tried the -a(average all frames) option in mlv_dump.osx on some 12 bit files for creating darkframes.
But the average file doesn't look right...it looks like a weird purple frame (when extracting the MLV files to dng's, I get normal black frames...)
Could it be that the average all frames option in mlv_dump doesn't work (yet ) on 10 and 12 bit files ?

['Canon']

Both videos show 'Delano Brouwers' as camera operator

This video on his vimeo page shows -> shot on 'Canon'
Don't know if he shot all the other videos on Canon.
The youtube videos do show a contact email, why don't ask them ?


http://vimeo.com/153281097

Just for information, I've got a few video files shot in 12 bit with wrong black level too, on the 6d.
I've shot about 25 mlv files during the day and got three files with green dark frames, never switched raw video settings, only turned camera on and off and adjusted diafragma and iso.
And did some switching between video and photo mode.

So it happens on multiple platforms.
Good to know where this weird green frames are coming from and how it is fixable

You need 1.1.6 for running magic lantern.
Last time it was still available on the Canadian official canon website

Yes that's possible.

Resolution setting is a little different compared to older builds.
in the raw video settings menu you can choose resolution, as you will see there aren't many options in the resolution menu anymore.
But you can finetune resolution by using the scroll wheel on top of your 6d, the resolution is adjustable in steps of 32 pixels.

For those of you that didn't know...
10 bit and 12 bit raw recording is now available on 6d, with working live view 

10 or 12 bit gives lower data stream which makes it possible to have longer recording times or use higher resolutions with the same recording time as before in 14 bit.
For example:
1728 x 724 resolution (1:2.39 aspect ratio) x 25 frames per second in 10 bit should give continuous recording
1728 x 972 resolution (16:9 aspect ration) x 25 frames per second in 10 bit gives about 20 seconds recording time

See this post including the download link:
http://www.magiclantern.fm/forum/index.php?topic=5601.msg176940#msg176940

Direct link to the builds:
https://bitbucket.org/daniel_fort/magic-lantern/downloads

Happy testing 

Is somebody willing to do a pull request for this for the 6d?

I can send the pieces of code that needs to be altered/added in a pm.

Yes confirmed, both values work

[#ifdef CONFIG_6D *width = zoom ? 2768 : mv720 ? 1920 : 1920; *height = zoom ? 988 : mv720 ? 662 : 1252; /* find correct mv720 height -- must be exact! */ return 1;#endif]

@eNnvi
I've tried the following dma flag as used for 700d
uint32_t dmaFlags = 0x20000000

And it causes the 'RAW DETECT ERROR' and when it will record it gives the scrambled frames.

So the only settings that were wrong in your build are the height value settings for the different video modes (width values were all good)
#ifdef CONFIG_6D
    *width  = zoom ? 2768 : mv720 ? 1920 : 1920;
    *height = zoom ? 988 : mv720 ?  662 : 1252;    /* find correct mv720 height -- must be exact! */   
    return 1;
#endif

And the dma flag setting, which must be either
uint32_t dmaFlags = 0x40000000 or uint32_t dmaFlags = 0x60000000

@Alex
uint32_t dmaFlags = 0x40000000
Works too, so before it didn't probably work because of the wrong resolution settings.

@Nikfreak
Submitting @bitbucket, what do you think I am, a developer 
And my coding skills aren't that good,in order to use the right dmaFlags my version, for sure, won't work for some other cams that worked before

@Danne
You're right, disabling stripe fix and cold pixel fix gives good frames.
But I always thought the stripe fix was nessecarry  ?

[Yep, 10 bit recording works flawlessly on the 6d, with live view]

Yep, 10 bit recording works flawlessly on the 6d, with live view

Although with 12 bit recording something weird is still going on (as mentioned before in this topic).
with 12 bit recording MLV_dump finds a lot of cold pixels and the image has specles all over it.

 
I tried the latest resolution values with this dma flag in edmac-memcpy.c

uint32_t dmaFlags = 0x60000000

And looks like we have working live view and NORMAL FRAMES on 6d 


I'll test some more, to be really sure it works 

Original values in the file from eNnvi were
*width  = zoom ? 2768 : mv720 ? 1920 : 1920;
*height = zoom ?  736 : mv720 ?  720 : 1208;

Don't know if I did it right, cause changing the debug.c and pushing the don't click me didn't change the values in the show edmac screens 
But these values I did found in one edmac channel:

zoom
4844 x 987 which translates too (2768 x 988)

1080mode
3360 x 1251  which translates too  (1920 x 1252)

720mode
3360 x 662  which translates too  (1920 x 662)

So my raw.c file is now like this (which still gives scrambled frames, but could be due other issues like free edmac channel etc.)
#ifdef CONFIG_6D
    *width  = zoom ? 2768 : mv720 ? 1920 : 1920;
    *height = zoom ? 988 : mv720 ?  662 : 1252;    /* find correct mv720 height -- must be exact! */   
    return 1;
#endif