Author Topic: Magic Lantern (RAW) Video format v2.0 (mlv_rec.mo) (Read 1448959 times)

RenatoPhoto · « **Reply #675 on:** October 19, 2013, 02:27:06 AM »

Probably not! Will have to test... Do you want to help?

PressureFM · « **Reply #676 on:** October 19, 2013, 10:34:15 AM »

Quote from: RenatoPhoto on October 19, 2013, 02:27:06 AM

Probably not! Will have to test... Do you want to help?

I can help test the 5D Mark II, if needed.

arrinkiiii · « **Reply #677 on:** October 19, 2013, 11:24:20 AM »

It's there any version for the 7D of the new mlv?

g3gg0 · « **Reply #678 on:** October 19, 2013, 11:54:01 AM »

its the same .mo as for the other models.

arrinkiiii · « **Reply #679 on:** October 19, 2013, 12:43:46 PM »

It's need to be compile? In the the first page i have download the pre_build but just find raw_rec.mo no mlv_rec.mo

Thanks =))

marekk · « **Reply #680 on:** October 19, 2013, 01:02:04 PM »

I would like to test mlv on 60D. How should I look for a msg_queue_count stub ?

g3gg0 · « **Reply #681 on:** October 19, 2013, 02:29:34 PM »

Let me check the missing stubs tonight

dariSSight · « **Reply #682 on:** October 19, 2013, 04:50:58 PM »

Quote from: g3gg0 on October 19, 2013, 02:29:34 PM

Let me check the missing stubs tonight

So does it work for 5D Mark II?

escho · « **Reply #683 on:** October 19, 2013, 08:55:47 PM »

You know this sigsegfault:

Code: [Select]

edgar@linux-lyl7:~/test> ./mlv_dump -r -o out.raw *.MLV

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

[i] Mode of operation:
   - Input MLV file: 'M18-2052.MLV'
   - Convert to legacy RAW
   - Output into 'out.raw'
[i] File M18-2052.MLV opened
[i] Processing...
[i] Unknown Block: NULL, skipping
Speicherzugriffsfehler

This error seems to appeare, if I compile mlv_rec on a linux-platform and try to run mlv_dump -r (I cannot test windows, because I don´t have windows).

A solution, that runs for me, is to change the void pointer in the raw_info struct in raw.h to uint:

Code: [Select]

/* raw image info (geometry, calibration levels, color, DR etc); parts of this were copied from CHDK */
struct raw_info {
   ...
    unsigned int buffer;               // points to image data
   ...
};

Now I have three questions:

1. Why do I have this sigsegfault, I told above, if I use the default pointer from raw.h and compile this whole stuff in Linux?

Code: [Select]

/* raw image info (geometry, calibration levels, color, DR etc); parts of this were copied from CHDK */
struct raw_info {
   ...
    void* buffer;               // points to image data
   ...
};

2. What can be changed in mlv_rec to avoid this problem? The solution with the unsigned int buffer gives a bunch of compiler warnings like this:

Code: [Select]

../../src/raw.c:842:33: warning: initialization makes pointer from integer without a cast [enabled by default]
../../src/raw.c: In function 'raw_green_pixel_dark':

3. Can we use my solution until we find a better way?, If yes, I`ll create a pull request.

Sorry, if I have to ask a little bit stupid, but I´m no programmer (but I try to learn a bit

)

Edgar

g3gg0 · « **Reply #684 on:** October 20, 2013, 12:41:10 AM »

Quote from: escho on October 19, 2013, 08:55:47 PM

You know this sigsegfault:

64 bit compiler?
can you update and try again?

g3gg0 · « **Reply #685 on:** October 20, 2013, 01:29:59 AM »

Quote from: dariSSight on October 19, 2013, 04:50:58 PM

So does it work for 5D Mark II?

yes

g3gg0 · « **Reply #686 on:** October 20, 2013, 02:21:07 AM »

Quote from: escho on October 19, 2013, 08:55:47 PM

1. Why do I have this sigsegfault, I told above, if I use the default pointer from raw.h and compile this whole stuff in Linux?

Code: [Select]
unsigned int buffer; // points to image data void* buffer; // points to image data;

on 32 bit systems, unsigned int is *usually* 32 bits, on 64 bit systems it is usually 64 bits.
memory pointers, no matter of which type behave the same way.

this is based on
- native register width
- memory address bus width
and compilers may do anything as long C standard is followed.
this even can result in unsigned int being 16 bit and char * being 64 bit.

thus developers are encouraged to use stdint.h where possible.
it defines uint32_t (8/16/32/64) types that are reliably of desired width.
as soon you write e.g. structs that should be read by other systems, you can be sure that
the other system doesnt get into trouble and reads crap.

well, still we all only think of little endian devices, so people with big endian ARM systems will
still have trouble in getting mlv_dump etc running.

escho · « **Reply #687 on:** October 20, 2013, 10:47:55 AM »

Quote from: g3gg0 on October 20, 2013, 12:41:10 AM

64 bit compiler?
can you update and try again?

Yes, 64 bit compiler. Now mlv_dump run without sigsegfault. Great!

And ThankYou for your detailed explanation.

Edgar

dariSSight · « **Reply #688 on:** October 21, 2013, 10:15:08 AM »

How do I use it for with my 5D Mark II?

oddname · « **Reply #689 on:** October 21, 2013, 04:50:11 PM »

Are there any pre-built modules working for the 5d2 that is newer than 10-3?

g3gg0 · « **Reply #690 on:** October 21, 2013, 05:03:01 PM »

the latest pre built module is from 13.10.2013.
you still have to compile the core binary for your model.

oddname · « **Reply #691 on:** October 21, 2013, 05:11:36 PM »

Guess Ill wait for the nightlies then =P

Me and compiling stuff... nah

taccca · « **Reply #692 on:** October 22, 2013, 01:38:55 PM »

Hey guys, long time follower and have loved using magic lantern on my 50D

I really know nothing about compiling, code etc but ive got my camera and are willing to test what ever you want if you point me in the right direction (ie, what/how exactly to load the module?? and how you want me to test it)

Ive got plenty of time (just had my knee reco last week) would love to help out wherever possible.

Cheers
Damien

RenatoPhoto · « **Reply #693 on:** October 22, 2013, 01:53:45 PM »

A small change is needed so that "make zip" command will include the mlv_rec.mo in the nightly builds. Should this be done so that mlv_rec.mo is tested across the different builds?

Andy600 · « **Reply #694 on:** October 25, 2013, 04:17:07 PM »

Still getting issues with random corrupt frames on the 50D and just wondering if the buffering method choices are different than those of raw_rec which I don't have any problems with?

It's frustratingly close to being useable but I can't risk dropping frames and there seems to be no pattern to where and when they appear in the footage. I'm using a KB 1000x card and tried even small frame sizes but the corrupt frames still make an appearance. I also have had shots with no crap frames.

I would love to try the 50D specific DPC to Log from Visioncolor with ACR but my mlv->raw->dng files (using freshly compiled mlv_dump.exe and raw2dng.exe) lose the metadata needed and it defaults to Canikon

How do you convert to legacy raw without losing metadata?

Also, the new mlv player is great! but seems to only work with the first mlv selected. The next mlv's selected make the idx files ok but drop out of the player and back to liveview. Bug?

loconetter · « **Reply #695 on:** October 25, 2013, 04:25:41 PM »

Just tried the new MLV format. However, the "mlv2dng" is not working, likely due to being on the new Mac OS 10.9. Any suggestions?

Thanks!

Nelson

Exception! Header not recognized: 'STYL'
dyld: lazy symbol binding failed: Symbol not found: __ZNKSt5ctypeIcE13_M_widen_initEv
Referenced from: /Volumes/Media1/MLV/./mlv2dng
Expected in: /usr/lib/libstdc++.6.dylib

dyld: Symbol not found: __ZNKSt5ctypeIcE13_M_widen_initEv
Referenced from: /Volumes/Media1/MLV/./mlv2dng
Expected in: /usr/lib/libstdc++.6.dylib

Trace/BPT trap: 5

g3gg0 · « **Reply #696 on:** October 25, 2013, 04:46:34 PM »

Quote from: loconetter on October 25, 2013, 04:25:41 PM

Just tried the new MLV format. However, the "mlv2dng" is not working, likely due to being on the new Mac OS 10.9. Any suggestions?

i dont develop mlv2dng.
the developer was told to NOT THROW errors when an unknown block is seen, because this will happen any time.
dont know why this still happens.

g3gg0 · « **Reply #697 on:** October 25, 2013, 04:58:16 PM »

Quote from: Andy600 on October 25, 2013, 04:17:07 PM

Still getting issues with random corrupt frames on the 50D and just wondering if the buffering method choices are different than those of raw_rec which I don't have any problems with?

is it better with lower frame rates?

Quote from: Andy600 on October 25, 2013, 04:17:07 PM

I would love to try the 50D specific DPC to Log from Visioncolor with ACR but my mlv->raw->dng files (using freshly compiled mlv_dump.exe and raw2dng.exe) lose the metadata needed and it defaults to Canikon How do you convert to legacy raw without losing metadata?

use mlv2dng

Quote from: Andy600 on October 25, 2013, 04:17:07 PM

Also, the new mlv player is great! but seems to only work with the first mlv selected. The next mlv's selected make the idx files ok but drop out of the player and back to liveview. Bug?

didnt try, will check.

Andy600 · « **Reply #698 on:** October 25, 2013, 05:08:21 PM »

Quote from: g3gg0 on October 25, 2013, 04:58:16 PM

is it better with lower frame rates?

No. I've tried down to 1fps and still get occasional bad frames

Quote

use mlv2dng

I just tried and it converts but model shows an error in the Exif info: ERR:1 md:0x 0 ml:0 (this is needed for the Visioncolor Log DCP)

core_32 · « **Reply #699 on:** October 25, 2013, 08:29:50 PM »

I've put CF and SD cards in my 5d3 and installed today's build - everything is working fine but I can't see the file spanning switch in the menus, my SD card seems not to be in use.
Any hint? Thanks.

upd: oops) I'm actually using raw_rec module) Am I right to think that mlv module isn't ready yet?

News:

Author Topic: Magic Lantern (RAW) Video format v2.0 (mlv_rec.mo) (Read 1448959 times)