Magic Lantern (RAW) Video format v2.0 (mlv_rec.mo)

[DesterWallaboo]

Should add that accidentally hitting the zoom button while recording in MLV will crash out ML and requires removal of the battery.

[1%]

That's kind of expected, you can't change the raw size in the middle of recording.

[andy kh]

adding audio meter for 650D possible with newer builds?

[g3gg0]

-> trying to isolate the reported crashes

[noix222]

just did a few tests with new build magiclantern-v2.3.NEXT.2014Mar10.5D3113 on my mark3 again shooting 30fps 1920x1080.

Im trying to get continuous 30fps 1920x1080 with mlv_rec. Today was weird it got straight 90mb/s from CF for a few seconds and soon the SD kicked in it pumped to 107mb/s continuous 30fps 1920x1080 recording in 1x mode ... booom . But that lasted just for a few more seconds when the speed dropped really quick and went back to same 98mb/s average witch is 80-81mb/s out of CF and 17mb/s on the SD. So at the end i was able to get nothing more than 30 seconds recording. I did more tests, same thing, the speed can go higher sometimes, but it is constant only around 97-98mb/s (80mb/s out of CF - 17mb/s out of SD) which doesn't really holds recording more than 30 seconds... i also tested record 3x mode.. still working pretty good it doesn't show continuous but i stopped recording after 1min.. and i could go more if i wanted too.   i guess it just needs to stabilize it in 1x mode . i wish i could help.

thanks.

[blakekimmel]

Is there a way to still shoot the old (Legacy?) RAW filetype on the current (early March) build? Having problems with pink vertical color stripes in MLV and people are saying they never had that problem with older RAW format.

I searched but couldn't find an answer.

[1%]

use raw_rec

[ted ramasola]

Pushing crop modes on the 5D2 and using MLV from ML nightlies Mar10.

I notice when using 2144x974  2.20:1 that there is a black pillar on the right side of the extracted DNGs.

This resolution is continuous at 20fps.

I'm hoping there can be a way that monitoring in crop mode can give a faster refresh with a way to get proper framing. This has so much potential.

[escho]

2 things:

1 mlv_dump doesn´t compile anymor per default, using make. In the makefile isn´t "all:: mlv_dump" anymore. I would linke to have this automation back.

2. mlv_dump shows a compile-error:

Code Select Expand

edgar@linux-uoww:~/ML/escho-magiclantern/modules/mlv_rec> make mlv_dump
../../Makefile.setup:101: BAD VALUE FOR CONFIG_SITE=/usr/share/site/x86_64-unknown-linux-gnu DEFAULTING TO n
[ HOST_CC  ]   mlv_dump.host.o
mlv_dump.c: In function 'main':
mlv_dump.c:1397:36: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
             xrefs = (mlv_xref_t *)((uint32_t)block_xref + sizeof(mlv_xref_hdr_t));
                                    ^
mlv_dump.c:2034:37: error: 'struct raw_info' has no member named 'buffer'
                             raw_info.buffer = frame_buffer;
                                     ^
make: *** [mlv_dump.host.o] Fehler 1

Edgar

edit:

forget to say: compiling newest build incl changeset: e86afc9 - Merged in mofig/mofig-magic-lantern/fontsdat (pull request #433)

[g3gg0]

1. 'make' or 'make all' per default compiles only the module, no PC tools. this improves automatic build scripts. please use 'make mlv_dump'
2. your default gcc is an x64 compiler. please update Makefile.user to match your x86 compiler

[escho]

ThankYou for the tips. Many things seems to be changed the last few days.

1. I will do so and use make mlv_dump (have to rewrite my install-script, no problem  )
2. Added -m32 to cflags and ldflags. Now it compiles.

Edgar

[Toffifee]

Where can I find a mlv2dng that has audio extraction? Hopefully for os x

[shambhu66]

Compilation fails on OSX Maverick after Xcode was upgraded to version 5.1 on March 10, 2014.

[Edit:] I should have added that ML autoexec.bin and modules compile OK without any issue even after the Xcode upgrade.
compilation fails only for mlv_dump.

Code Select Expand

[ HOST_CC  ]   mlv_dump.host.o
clang: error: unknown argument: '-mno-ms-bitfields' [-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning) in the future
make: *** [mlv_dump.host.o] Error 1

This did not help either:
export CFLAGS=-Qunused-arguments
export CPPFLAGS=-Qunused-arguments

Removed '-mno-ms-bitfields' from modules/mlv_rec/Makefile, but ld was not happy.

MLV_CFLAGS = -I$(SRC_DIR) -D MLV_USE_LZMA -m32 -Wpadded  -D _7ZIP_ST -D MLV2DNG

Code Select Expand

ld: warning: ld: warning: ignoring file ../../src/chdk-dng.host.o, file was built for i386 which is not the architecture being linked (x86_64): ../../src/chdk-dng.host.oignoring file mlv_dump.host.o, file was built for i386 which is not the architecture being linked (x86_64): mlv_dump.host.o

ld: warning: ignoring file ../lv_rec/raw2dng.host.o, file was built for i386 which is not the architecture being linked (x86_64): ../lv_rec/raw2dng.host.o
ld: warning: ignoring file lzma/lib7z.a, file was built for archive which is not the architecture being linked (x86_64): lzma/lib7z.a
Undefined symbols for architecture x86_64:
  "_main", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [mlv_dump] Error 1

Removed -m32 from modules/mlv_rec/Makefile, no luck either.

MLV_CFLAGS = -I$(SRC_DIR) -D MLV_USE_LZMA -Wpadded -D _7ZIP_ST -D MLV2DNG

Code Select Expand

Macintosh:mlv_rec okumar$ make clean && make mlv_dump
[ RM ]  mlv_rec.o mlv.o mlv_rec.mo mlv_rec.sym mlv_rec.dep module_strings.h *.o *.d *.dep *.sym hgstamp
[ RM ]  mlv_dump mlv_dump.exe lzma/7zAlloc.host.o lzma/7zBuf.host.o lzma/7zBuf2.host.o lzma/7zCrc.host.o lzma/7zCrcOpt.host.o lzma/7zDec.host.o lzma/7zFile.host.o lzma/7zIn.host.o lzma/7zStream.host.o lzma/Alloc.host.o lzma/Bcj2.host.o lzma/Bra.host.o lzma/Bra86.host.o lzma/BraIA64.host.o lzma/CpuArch.host.o lzma/Delta.host.o lzma/LzFind.host.o lzma/Lzma2Dec.host.o lzma/Lzma2Enc.host.o lzma/Lzma86Dec.host.o lzma/Lzma86Enc.host.o lzma/LzmaDec.host.o lzma/LzmaEnc.host.o lzma/LzmaLib.host.o lzma/Ppmd7.host.o lzma/Ppmd7Dec.host.o lzma/Ppmd7Enc.host.o lzma/Sha256.host.o lzma/Xz.host.o lzma/XzCrc64.host.o lzma/lib7z.a lzma/Threads.w32.o lzma/LzFindMt.w32.o lzma/MtCoder.w32.o lzma/7zAlloc.w32.o lzma/7zBuf.w32.o lzma/7zBuf2.w32.o lzma/7zCrc.w32.o lzma/7zCrcOpt.w32.o lzma/7zDec.w32.o lzma/7zFile.w32.o lzma/7zIn.w32.o lzma/7zStream.w32.o lzma/Alloc.w32.o lzma/Bcj2.w32.o lzma/Bra.w32.o lzma/Bra86.w32.o lzma/BraIA64.w32.o lzma/CpuArch.w32.o lzma/Delta.w32.o lzma/LzFind.w32.o lzma/Lzma2Dec.w32.o lzma/Lzma2Enc.w32.o lzma/Lzma86Dec.w32.o lzma/Lzma86Enc.w32.o lzma/LzmaDec.w32.o lzma/LzmaEnc.w32.o lzma/LzmaLib.w32.o lzma/Ppmd7.w32.o lzma/Ppmd7Dec.w32.o lzma/Ppmd7Enc.w32.o lzma/Sha256.w32.o lzma/Xz.w32.o lzma/XzCrc64.w32.o lzma/lib7z.w32.a
[ HOST_CC  ]   mlv_dump.host.o
mlv_dump.c:2034:38: error: no member named 'buffer' in 'struct raw_info'
                            raw_info.buffer = frame_buffer;
                            ~~~~~~~~ ^
1 error generated.
make: *** [mlv_dump.host.o] Error 1

[chmee]

just leaving a note. raw2cdng is supporting mlv+audio now as well.
http://www.magiclantern.fm/forum/index.php?topic=5618.msg106173#msg106173

[alexpolsky]

Hello!I do not dump mlv file in raw or in dng with mlv_dump & MlRawViewer (OSX)
In MlRawViewer playing stoping on 46 frames and app hangs(Other video good play and converting on dng.
In mlv_dump this log
Mac-Pro-MacMan:Movie macman$ ./mlv_dump -f30 M07-2323.mlv out.raw

MLV Dumper v1.0
-----------------

Mode of operation:
   - Input MLV file: 'M07-2323.mlv'
   - Verify file structure
File M07-2323.mlv opened
File M07-2323.m00 opened
File M07-2323.m01 not existing.
File M07-2323.IDX opened (XREF)
XREF table contains 323 entries
Processing...
Reached end of all files after 323 blocks
Processed 299 video frames
Done
I don't have M07-2323.m01 on SD or CF card.

Is it possible dump to from a particular frame. Because if you miss the 46 frame video on playing in MlRawViewer.
Sorry my english. I am from Ukraine.  Please help!

[a1ex]

Recompiling nightly builds to undo a change that made mlv_rec+mlv_play completely unusable on 5D2 and other DIGIC IV cameras (to reproduce, simply record a short clip and play it back in the camera).

Issue discussed here:
https://bitbucket.org/hudson/magic-lantern/pull-request/438/raw-recording-force-line-size-to-be/diff#comment-1409162
https://bitbucket.org/hudson/magic-lantern/commits/249d4ea65d3679df6a8591ec1af9087dc6c3078f

[noix222]

im still testing new builds (magiclantern-Nightly.2014Mar15.5D3113) on my 5d mk 3... the speed at 3x mode is amazing it holds 103mb/s and i can continuous record 1920x1080 30fps... but again recording at 1x mode the speed drops to 97mb/s... and stops just after 25 seconds.

[tjaja]

Noix222 if there arent any changes in the module there Will be no changes in speed. Check the changelog or set to see if there are changes in mlv_rec before comparing nightlies.

[mixmastermike]

Noix222 if there arent any changes in the module there Will be no changes in speed. Check the changelog or set to see if there are changes in mlv_rec before comparing nightlies.

Fair point, I do have  a question though is this reduction in write speed in 1x mode likely to be sorted out in the future? or will it stay as such?

[tonybeccar]

I have a question regarding the MLV header. I'm trying to read the metadata in it, which until so far I have *almost* success. What happens is that the header is not always exact, it varies sometimes by camera model and always varies if you have 'text' or 'take' entries (also depending on the lens model length). What my converter does is to read for example byte number 34, which is the ISO, and boom I get the value. Now, if some entry from 'text' field is present (for example), all bytes in the header shift because of the 'text' length, so the ISO isn't now on byte 34 but on 40 (for example), that causes in erroneous reads of the metadata.

Does anyone know any logic or workaround for this? I'm a rookie programmer but I can manage... But I just don't understand how can it be done. How can I identify a byte that can be anywhere?

Thanks and hope someone could point me in the right direction.
Cheers!

Tony.

[g3gg0]

Does anyone know any logic or workaround for this? I'm a rookie programmer but I can manage... But I just don't understand how can it be done. How can I identify a byte that can be anywhere?

as the file format description suggests, you have to identify the block by its type (LENS, VIDF, AUDF, etc)
if the block you currently have is not of any interest for you, just skip the block. for that you have the blocksize field.

[noix222]

Noix222 if there arent any changes in the module there Will be no changes in speed. Check the changelog or set to see if there are changes in mlv_rec before comparing nightlies.

yes your right.. i do that actually.. i've seen a few mlv cleanups and etc from g3gg0 in the changelog a day before or so and because i haven't tested for about 2 or 3 days.... i thought it could have changed something. Just posting reports after 2 or 3 builds and only if there's g3gg0 or a1ex changes..

[gideonplus]

I had Just tested the 1.2.3 on my 5D3 , Thanks for the Excellent work.
The raw rec was good up to 1920x1080x25p (Normal and crop mode).
But the MLV Raw doesnt work for me more than 1 min (4GB) and then it dumps some debug info about QUED something.
a sample of Logfile that was made to the root dir :

ML ASSERT:
hdr->blockSize >= (sizeof(mlv_vidf_hdr_t) + hdr->frameSpace + frame_size)
at mlv_rec.c:1990 (process_frame), task Evf
lv:1 mode:3
Magic Lantern version : Nightly.2014Mar16.5D3123
Mercurial changeset   : a9dced4a127b (5D3-123) tip
Built on 2014-03-16 13:26:55 UTC by [email protected].
Free Memory  : 165K + 3742K

[g3gg0]

thanks, will check that.
looks like the additional check catched a bug

[gideonplus]

Tested again the 1.2.3 on my 5D3 and some of the MLV files had
a green tint and in addition some where very dark
(compared to other files with same EXPO.)
using rec raw it was ok.