MLVFS - a FUSE based, "on the fly" MLV to CDNG converter

[reddeercity]

Thanks Guys !  Just doing my Part : I like doing ML Tutorial , it let me take a brake from my
paid project as I'm in the really boring part  "grading" indie movie .
It can be exciting sometimes ! when a image come to life though hours & hours of works 
then you sit back , look at it and go " I  Love "F"ing Raw"   

Only 520 clips to go  , that what keep telling myself 519 to go ,  518 to go ,  517 to go .......
Done 500 already   

[USADavid]

Is anyone else having empty .wav files with .MLV files > 2GB on Mac?
Plays fine with MlRawViewer!

[ruber]

Hi Guys,

thx to your good tips, I am working on a project with mlvfs and Dokan for the first time

I am in windows 10 pro, working with Davinci Resolve right now.

Clips are 1080p 25fps (NO dual iso)
My camera is the 5dmk3

I have succesfully imported all the clips (about 50 files) into davinci but the problem now is that playback is really slow, it stutters and it's not possible to work this way

Surprinsingly, when I deliver (render) one of these clips, rendering speed is quite good (40fps minimum with DNxHD)

EDIT: now playback in timeline is smooth and that's the most important thing. The problem is when I play the clips in the "media" section.

Would you have some tips?

Thank you. Cheers.

[markodarko]

Firstly, thank you @dmilligan for developing this solution for the community. It really is most excellent. I wonder if it would be possible for you to answer these questions for me as my search on this forum didn't bring up any:

1. What is the difference between "On" and "Aggressive" for bad pixel correction in terms of use and speed differences (if any)?
2. What are the differences in speed between opening the cDNGs using MLVFS or by first copying out the cDNG files to a folder and opening them there?

I ask because rendering 1080p clips from my 5D III in DaVinci Resolve 12 Lite is painfully slow for me. I have a MBP i7 8Gb RAM / 512Mb Nvidia with 512Gb SSD system drive and 2TB SSD media drive installed and rendering a 2 minute clip to ProRes 4444 with "Aggressive" bad pixel correction (as "on" didn't get rid of them) as well as colour grading in Resolve took 6 hours. I'm currently rendering another timeline with various clips and a total duration of 4 minutes and the estimated render time is SIXTEEN hours - it's 11 hours in right now so I'm not going to stop it to do some tests at this point.

I'd just like to get to the bottom of where the bottleneck is (aside from my mediocre Mac system compared to today's standards!) as I've read that others are getting 40fps render times. Is it the "Aggressive" mode or is it opening the cDNG files directly instead of first copying them?

Thanks for your help,

Mark.

EDIT: I just stopped the render as it was ridiculous so I'm going to do some tests. Incidentally, MLVFS is using a lot of RAM...

[dmilligan]

Incidentally, MLVFS is using a lot of RAM...

I've fixed some memory leaks recently, maybe I haven't updated the build, I'll check.

[Markus]

@markodarko
If bad pixel fix slows down your process much you can get rid of the bad pixel with a secondary node in resolve instead. You make super small masks that blur out the stuck pixels. It's quite tiresome and fiddely to make masks for all the bad pixels but once you have done it you can save all the masks as a preset that you can reuse later since the bad/stuck pixels will be in the same places.

[markodarko]

I've fixed some memory leaks recently, maybe I haven't updated the build, I'll check.

Ah ok. I'm not sure which build I have. Perhaps you could amend the http://localhost:8000 control page to display the current build of MLVFS installed to make checking if we're running the latest version easier?

If bad pixel fix slows down your process much you can get rid of the bad pixel with a secondary node in resolve instead. You make super small masks that blur out the stuck pixels. It's quite tiresome and fiddely to make masks for all the bad pixels but once you have done it you can save all the masks as a preset that you can reuse later since the bad/stuck pixels will be in the same places.

Funny you should mention this as I was going to shoot a black matte at high ISO to make just a power grade with the technique you mentioned! Great minds an' all that...

But I think I've discovered the culprit, speed wise. I did some tests with a 60Gb cDNG folder and copying it to various places.

1. Bad Pixel Fix = "Aggressive". Copying from MLVFS > HDD took 130 minutes.
2. Bad Pixel Fix = "Off". Copying from MLVFS > HDD took 11 minutes.
3. Copying the copied folder to another location on my HDD took 7 minutes.

So from my quick test it takes 11 times longer with "Aggressive" but when set to "Off" it's only 1.5 longer than copying from HDD to HDD (only SATA II on this laptop unfortunately) so MLVFS is incredibly fast when set to "Off". Obviously, 130/7 = 18 times quicker when opening the copied DNGs directly from my HDD.

I'm now going to do another test in Resolve whereby I open the copied folders instead of the MLVFS folders to see if there's any significant difference in UI / Playback / Rendering speed over opening from MLVFS directly.

Cheers,

Mark.

[dmilligan]

Perhaps you could amend the http://localhost:8000 control page to display the current build of MLVFS installed to make checking if we're running the latest version easier?

I already have so if you don't seen version info at the bottom of the page, you must be running an old version.

A good way to measure speed is to cat the DNGs to /dev/null and time that. That way there's no dependency on the write speed of destination drive (in *nix, /dev/null is just an empty place to dump data, it goes nowhere). In the terminal:

Code Select Expand


time cat <path-to-mlvfs-mount>/<path-to-mlv-dir>/*.dng > /dev/null


Example:

Code Select Expand


$ time cat ~/MLVFS/M14-2300.MLV/*.dng > /dev/null

real 0m6.936s
user 0m0.016s
sys 0m0.782s


[voblaunsane]

Win 7 context menu "Mount with MLVFS" with Admin rights elevation

mlvfs.reg - run this to create registry entry adding "Mount with MLVFS" context menu option to every folder.

Code Select Expand

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\shell\MLVFS]
@="Mount with MLVFS"

[HKEY_CLASSES_ROOT\Directory\shell\MLVFS\command]
@="\"C:\\Program Files\\MLVFS_x64\\mlvfs.bat\" \"%1\""

mlvfs.bat - place this file next to mlvsf_x64.exe

Code Select Expand

@echo Off
Setlocal
:: First check if we are running As Admin/Elevated
FSUTIL dirty query >nul
if %errorlevel% EQU 0 goto START

::Create and run a temporary VBScript to elevate this batch file
set _batchFile=%~f0
set _Args=%*
:: double up any quotes
set _batchFile=""%_batchFile:"=%""
set _Args=%_Args:"=""%

echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%\~ElevateMe.vbs"
echo UAC.ShellExecute "cmd", "/c ""%_batchFile% %_Args%""", "", "runas", 1 >> "%temp%\~ElevateMe.vbs"

cscript "%temp%\~ElevateMe.vbs"
exit /B

:START
:: set the current directory to the batch file location
cd /d %~dp0

:: run webgui
start http://localhost:8000

:: run mlvfsx64
mlvfs_x64.exe x:\ --mlv_dir=%1
:: -d 1>log_std-out-err.txt 2>&1

You might need to modify paths to fit your setup.. and voilà!

[markodarko]

I already have so if you don't seen version info at the bottom of the page, you must be running an old version.

Ha. No problem. Have just updated.

A good way to measure speed is to cat the DNGs to /dev/null and time that.

Great tip, thanks! I shall use that in future. For now though as I have some historic time data I re-ran my jobs after re-linking the media to cDNGs that I'd copied from the MLVFS volume with the "Aggressive" flag set. As to be expected it has made a massive difference doing it that way. A job which took 12.5hrs to render now took only 1.5hrs.

There's no real noticeable difference in rendering speed as far as I can see (in my admittedly un-scientific tests) between jobs that are rendered via cDNGs that are opened directly via MLVFS with the Fix Pixel flag set to OFF or copied cDNGs. The only slow-down seems to be when setting the Fix Pixel flag to Aggressive. In that instance it seems much quicker to first copy out the cDNGs from MLVFS to a new folder with the flag set to "aggressive" (took 2hrs) and then relink the media to the copied files rather than opening them directly through MLVFS.

This is on my machine of course and with the clips fully graded in Resolve - i.e., they're not simply "spat out" the other side in delivery from the source clips. I'd imagine that would speed things up dramatically too.

Cheers,

Mark.

[dmilligan]

We can actually make the bad pixel fix considerably faster by only analyzing one frame and then simply applying the correction to those pixels in all frames. This should work in theory since bad pixels are typically fixed. I've updated the Mac download with a build that implements this. Please let me know how it's working. Also fixed is the TC issue @dfort found.

[markodarko]

We can actually make the bad pixel fix considerably faster by only analyzing one frame and then simply applying the correction to those pixels in all frames. This should work in theory since bad pixels are typically fixed. I've updated the Mac download with a build that implements this. Please let me know how it's working. Also fixed is the TC issue @dfort found.

But does the bad pixel feature not take into account corresponding colours when it "blends"?

May I ask what is the difference between "On" and "Aggressive" in terms of what's happening to the image?

Thanks,

Mark.

[dfort]

Also fixed is the TC issue @dfort found.

Thanks! I just checked it and it looks good on 23.976 material. I'd like to check it out on 29.97 because it looks like you're using drop-frame timecode.

I also checked a 59.94 MLV--I've got some ideas for that but want to think about it first.

[dmilligan]

But does the bad pixel feature not take into account corresponding colours when it "blends"?

99.999% of the time spent by the bad pixel fix feature is *looking* for bad pixels (you have to check each and every pixel, and there are millions, and analyze all of it's neighbors) and the tiny remainder is the time to *correct* them (there are typically only a few hundred to thousand to correct). We only need to *look* for bad pixels in the first frame, then we store which pixels were bad and correct those pixels in each subsequent frame.

what is the difference between "On" and "Aggressive" in terms of what's happening to the image?

'Aggressive' has lower thresholds for what is considered a "bad" pixel. Therefore it will include more pixels (and probably more false positives) in the list of pixels it considers to be corrected, but it's more likely to identify bad pixels that don't stand out as much, but are still bad pixels.

@dfort, just FYI: the bad pixel fix algorithm will print to stdout the list of bad pixels it finds, so if you have focus pixel footage where you can really make the focus pixels standout, this might be a good check or starting point for creating focus pixels maps.

[Ottoga]

@dmilligan

So does bad pixel equate to hot pixel in ML speak and recovery process?

I would define a bad pixel as one which is say permanently off (dead) or permanently stuck to a specific colour. I can see analysis the first frame only working for these. Whereas a hot pixel may not manifest itself until some time after the camera has been in use, specifically when the camera starts to get hot. if this true then only checking the first frame would risk missing these.

If you have to have a separate process for hot verses bad pixels would defeat the purpose of your proposed bad pixel management. Don't get wrong, I like the idea. Just thinking out loud of a potential pitfall that could just lead whole new slew of support issues.

Apologies if my thoughts are a pile of nonsense.

[dmilligan]

Well, we can always just analyze the last frame, though it's not impossible for a camera to actually cool down, and there are other things besides temperature that influence behavior.

An ideal algorithm would probably pick a handful of frames and use all of them *together* to find stuck pixels, but such a complex algorithm is beyond the amount of free time I have to work on this project. Additionally, Resolve Lite is pretty much the only software that doesn't automatically take care of these anyway (and I don't use Resolve personally).


On a side note, from my understanding there's no real difference in "hot" pixel and "stuck" pixel, they are caused by the same phenomenon, there are just various levels of "hotness" a pixel can have. There does tend to be a non-linear response to the various parameters that effect them (temperature, ISO, exposure time, etc.), which gives the impression that some pixels are always "stuck" and some are only "hot", but really the "hot" ones are just on the more linear side of the non-linear response, and the "stuck" ones are past the "elbow".

[DeafEyeJedi]

Any Mac users experiencing the web GUI error with the latest MLVFS update from today even though it kind of works but in a weird way?

I'm not sure why this is happening on my end now when it just worked fine last night.

Basically right after the web GUI error I went ahead and opened up the Virtual Folder which somehow had all the Files w DNG's in it but no .IDX would spit out UNLESS I manually go through each Folder which then spits out .IDX for each however still I have no controls over web GUI since it doesn't show anything.

Here's the screenflow of what I was able to accomplish despite of the new bug:

https://vimeo.com/160190883

[dmilligan]

Logs?

Try rebooting your computer.

[DeafEyeJedi]

Actually for some reason last night after a few restarts ... problem still persisted and gave up but then this morning when I woke up and decided to do a hard reboot and volia you were right on that one. Oops, my bad I guess? 

Running Version: 109ac1a Mar 22 201621:26:57 and all is well so I'll be testing out the TC feature and will report back when I can.

Thanks again, David!

[markodarko]

99.999% of the time spent by the bad pixel fix feature is *looking* for bad pixels (you have to check each and every pixel, and there are millions, and analyze all of it's neighbors)

Ah, of course. Makes sense.

An ideal algorithm would probably pick a handful of frames and use all of them *together* to find stuck pixels, but such a complex algorithm is beyond the amount of free time I have to work on this project.

I understand. How about a third option, that is to keep the "Aggressive" flag as it was (i.e., checking every frame) and add another setting to the UI called "Aggressive (first frame check only)"? That way if we experience hot pixels due to camera heat / cooling down etc then we could choose the "every frame" option but otherwise just use the "quick" option... Thoughts?

Incidentally, I have a problem running MLVFS from a certain drive. It results in a crash:

Code Select Expand


Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000027800000010
Exception Note:        EXC_CORPSE_NOTIFY


I can send you the full crash report if you want.

Basically I moved all of my MLV files to an external Raid 0 drive and tried to mount the MLV folder from there. It goes through the process of showing the "choose your mount point" window but as soon as I do it opens Safari to a blank page saying that it could not open the page.

I've tried having the mount folder locally and on the external drive but to no avail.

I've set the privileges on the drive to "Read & Write" for me, "Staff" and "Everyone" as I assume it's a write error?

This does not happen with all external drives. Works fine with another external SSD drive that I have.

Cheers,

Mark.

EDIT: I've found the problem with the error. It seems that MLVFS doesn't like spaces (or it could be brackets) in the drive name. I renamed the drive to use underscores instead of spaces (and removed the brackets) and all now works as expected.

[dmilligan]

EDIT: I've found the problem with the error. It seems that MLVFS doesn't like spaces (or it could be brackets) in the drive name. I renamed the drive to use underscores instead of spaces (and removed the brackets) and all now works as expected.

Cannot reproduce. Spaces and brackets work fine here. Upload the whole crash log and also ~/mlvfs.log. Can you reproduce the issue if you change the name back to what it was? What exactly was the drive name and what format?

[markodarko]

Cannot reproduce. Spaces and brackets work fine here. Upload the whole crash log and also ~/mlvfs.log. Can you reproduce the issue if you change the name back to what it was? What exactly was the drive name and what format?

Can't seem to find mlvfs.log on my system but changing the name back resulted in the same error:




The volume format is Mac OS Extended (Journaled) and the name was "MLV Backup (Samsung 2TB)". Maybe it's the length of the name?

Here's the latest crash report:

Code Select Expand

Process:               mlvfs [427]
Path:                  /Users/USER/Library/Services/*/mlvfs
Identifier:            mlvfs
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           mlvfs [427]
User ID:               501

Date/Time:             2016-03-26 15:55:21.382 +0000
OS Version:            Mac OS X 10.11.3 (15D21)
Report Version:        11
Anonymous UUID:        2F2B3BBB-6F28-0BF2-82FE-21ED37D41433


Time Awake Since Boot: 75 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000027800000010
Exception Note:        EXC_CORPSE_NOTIFY

VM Regions Near 0x27800000010:
    Process Corpse Info    000000010a53b000-000000010a73b000 [ 2048K] rw-/rwx SM=COW 
-->
    MALLOC_TINY            00007fc382c00000-00007fc382e00000 [ 2048K] rw-/rwx SM=PRV 

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_c.dylib              0x00007fff93f54152 strlen + 18
1   libsystem_c.dylib              0x00007fff93faeb79 strdup + 18
2   mlvfs                          0x0000000107af5d25 main + 309
3   libdyld.dylib                  0x00007fff8a2395ad start + 1

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000001  rbx: 0x0000000000000000  rcx: 0x0000027800000019  rdx: 0x0000027800000019
  rdi: 0x0000027800000010  rsi: 0x00007fff64bea248  rbp: 0x00007fff5810caa0  rsp: 0x00007fff5810caa0
   r8: 0x0000000000000000   r9: 0x00007fc382d00145  r10: 0x00007fff9bcb7f01  r11: 0x00007fff93faeb67
  r12: 0x0000000000000000  r13: 0x0000000000000000  r14: 0x0000027800000019  r15: 0x0000000000000000
  rip: 0x00007fff93f54152  rfl: 0x0000000000010202  cr2: 0x0000027800000010
 
Logical CPU:     2
Error Code:      0x00000004
Trap Number:     14


Binary Images:
       0x107af3000 -        0x107b61ff7 +mlvfs (0) <FE4AA6CB-2C80-3284-BEEC-C38549A7E38A> /Users/USER/Library/Services/*/mlvfs
       0x10a2d8000 -        0x10a2f6fe7 +libosxfuse_i64.2.dylib (10.3) <B953F9DD-EF0F-3FA6-AB08-D8D96131C9CE> /usr/local/lib/libosxfuse_i64.2.dylib
    0x7fff64bea000 -     0x7fff64c21007  dyld (360.19) <9D05FDF4-65CE-3B53-86D4-ABE1A5BF35F3> /usr/lib/dyld
    0x7fff84f05000 -     0x7fff84f21ff7  libsystem_malloc.dylib (67) <9EECAB18-F025-34C4-8E32-7EFFA6720EFC> /usr/lib/system/libsystem_malloc.dylib
    0x7fff8798f000 -     0x7fff87997fff  libcopyfile.dylib (127) <F5133269-0B22-388C-A57C-079667B6291E> /usr/lib/system/libcopyfile.dylib
    0x7fff87f9d000 -     0x7fff87f9dff7  libunc.dylib (29) <1D0F8265-F026-3CBD-93D3-F8DF14FFCE68> /usr/lib/system/libunc.dylib
    0x7fff89117000 -     0x7fff8911aff7  libsystem_sandbox.dylib (460.30.1) <3E0036AF-FC64-3352-8DA4-6B550C2C2562> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff8977a000 -     0x7fff897a9ffb  libsystem_m.dylib (3105) <26655445-CA97-321E-B221-801CB378D1AA> /usr/lib/system/libsystem_m.dylib
    0x7fff899ae000 -     0x7fff89aa0ff7  libiconv.2.dylib (44) <F05A0A5A-92A9-3668-8F20-F27CBDA26BE9> /usr/lib/libiconv.2.dylib
    0x7fff89aa1000 -     0x7fff89b02ff7  libsystem_network.dylib (583.20.10) <865FE79A-A22D-3733-A14F-FC7B37F3AECD> /usr/lib/system/libsystem_network.dylib
    0x7fff89b31000 -     0x7fff89b48ff7  libsystem_asl.dylib (322.30.1) <9B500E4E-E462-321E-828E-5524DC984C1B> /usr/lib/system/libsystem_asl.dylib
    0x7fff89c92000 -     0x7fff89e9fffb  libicucore.A.dylib (551.41) <CFFD7342-A7D6-323A-AC14-B9EECF6EFFED> /usr/lib/libicucore.A.dylib
    0x7fff8a236000 -     0x7fff8a239ffb  libdyld.dylib (360.19) <AA629043-C6F6-32FE-8007-E3478E99ACA7> /usr/lib/system/libdyld.dylib
    0x7fff8b048000 -     0x7fff8b08eff7  libauto.dylib (186) <999E610F-41FC-32A3-ADCA-5EC049B65DFB> /usr/lib/libauto.dylib
    0x7fff8b4ed000 -     0x7fff8b50bfff  libsystem_kernel.dylib (3248.30.4) <9CEB6C3B-1CAF-3C32-A9FD-93BC72CBCEA1> /usr/lib/system/libsystem_kernel.dylib
    0x7fff8b581000 -     0x7fff8b581ff7  liblaunch.dylib (756.20.4) <EDF719D6-D2BB-38DD-8C94-4272BEFDA2CD> /usr/lib/system/liblaunch.dylib
    0x7fff8b5b0000 -     0x7fff8b5b0ff7  libkeymgr.dylib (28) <09397E01-6066-3179-A50C-2CE666FDA929> /usr/lib/system/libkeymgr.dylib
    0x7fff8b5e7000 -     0x7fff8b5f0ff7  libsystem_pthread.dylib (138.10.4) <327CECD0-B881-3153-8FCC-4FD4818B7F16> /usr/lib/system/libsystem_pthread.dylib
    0x7fff8ba5c000 -     0x7fff8ba89fff  libdispatch.dylib (501.20.1) <324C9189-2AF3-3356-847F-6F4CE1C6E901> /usr/lib/system/libdispatch.dylib
    0x7fff8c76a000 -     0x7fff8c76bffb  libSystem.B.dylib (1226.10.1) <5A4257EF-3145-3BB3-87A4-0D2404A9462D> /usr/lib/libSystem.B.dylib
    0x7fff8cbef000 -     0x7fff8d065fff  com.apple.CoreFoundation (6.9 - 1256.14) <768A7FB7-9143-3148-8591-7C6ED3162D35> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff8d06c000 -     0x7fff8d074fe7  libsystem_platform.dylib (74.10.3) <D3A27E10-7F08-3603-ACC8-7A92B2C04BAB> /usr/lib/system/libsystem_platform.dylib
    0x7fff8d58e000 -     0x7fff8d590ff7  libquarantine.dylib (80) <163CF63A-7455-3D1F-AE57-8C4475A9204C> /usr/lib/system/libquarantine.dylib
    0x7fff8d591000 -     0x7fff8d5e4ff7  libc++.1.dylib (120.1) <8FC3D139-8055-3498-9AC5-6467CB7F4D14> /usr/lib/libc++.1.dylib
    0x7fff901b1000 -     0x7fff901b3ff7  libsystem_configuration.dylib (802.20.7) <5FD79070-36CC-3D02-BEA7-BB5D2AE97D5D> /usr/lib/system/libsystem_configuration.dylib
    0x7fff910de000 -     0x7fff910e2fff  libcache.dylib (75) <6B245C0A-F3EA-383B-A542-5B0D0456A41B> /usr/lib/system/libcache.dylib
    0x7fff937bb000 -     0x7fff937e4fff  libsystem_info.dylib (477.20.1) <6513635B-4ADE-3B45-BF63-ED7AC565B0C9> /usr/lib/system/libsystem_info.dylib
    0x7fff93f44000 -     0x7fff93f45fff  libsystem_secinit.dylib (20) <FD6ECF2C-1489-32CA-981B-9045B5EB1FAA> /usr/lib/system/libsystem_secinit.dylib
    0x7fff93f53000 -     0x7fff93fe0fff  libsystem_c.dylib (1082.20.4) <EAB38A6C-8671-3B13-B500-90EC1B912063> /usr/lib/system/libsystem_c.dylib
    0x7fff94718000 -     0x7fff94720fff  libsystem_networkextension.dylib (385.20.6) <DC8A102A-BF02-31A4-8914-65C34DF6B592> /usr/lib/system/libsystem_networkextension.dylib
    0x7fff9478c000 -     0x7fff9478dfff  libDiagnosticMessagesClient.dylib (100) <4243B6B4-21E9-355B-9C5A-95A216233B96> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff9526b000 -     0x7fff95273ffb  libsystem_dnssd.dylib (625.20.4) <945B5FB1-DA91-3D45-A961-A8FAD53C1E7E> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff95508000 -     0x7fff95509ffb  libremovefile.dylib (41) <B8D1A5FC-CFD5-3AAB-8A10-14DDC129710A> /usr/lib/system/libremovefile.dylib
    0x7fff955ee000 -     0x7fff95617fff  libc++abi.dylib (125) <DCCC8177-3D09-35BC-9784-2A04FEC4C71B> /usr/lib/libc++abi.dylib
    0x7fff957bc000 -     0x7fff957bdfff  libsystem_blocks.dylib (65) <49D42329-7DE9-3413-92C3-A473A7E9CF35> /usr/lib/system/libsystem_blocks.dylib
    0x7fff95bf7000 -     0x7fff95c00ff3  libsystem_notify.dylib (150.20.3) <243FADE1-255A-3B78-8033-F336CD64B817> /usr/lib/system/libsystem_notify.dylib
    0x7fff9615f000 -     0x7fff96164ff7  libmacho.dylib (875.1) <CB745E1F-4885-3F96-B38B-2093DF488FD5> /usr/lib/system/libmacho.dylib
    0x7fff96629000 -     0x7fff9662bfff  libsystem_coreservices.dylib (19.2) <1B3F5AFC-FFCD-3ECB-8B9A-5538366FB20D> /usr/lib/system/libsystem_coreservices.dylib
    0x7fff96a33000 -     0x7fff96a38ff3  libunwind.dylib (35.3) <124E0F05-2350-3774-A32C-7F5BF38EDE73> /usr/lib/system/libunwind.dylib
    0x7fff96ca0000 -     0x7fff96cabff7  libcommonCrypto.dylib (60075.20.1) <766BC3F5-41F3-3315-BABC-72718A98EA92> /usr/lib/system/libcommonCrypto.dylib
    0x7fff96f8d000 -     0x7fff96f94ff7  libcompiler_rt.dylib (62) <D3C4AB40-23B4-3BC6-8C38-5B8758D14E80> /usr/lib/system/libcompiler_rt.dylib
    0x7fff97028000 -     0x7fff97039ff7  libz.1.dylib (61.20.1) <B3EBB42F-48E3-3287-9F0D-308E04D407AC> /usr/lib/libz.1.dylib
    0x7fff97840000 -     0x7fff97851ff7  libsystem_trace.dylib (201.10.3) <B485369F-E3A1-319E-998C-89AAF606079E> /usr/lib/system/libsystem_trace.dylib
    0x7fff9896f000 -     0x7fff98cda657  libobjc.A.dylib (680) <58CB8CFC-7DBD-3A53-BD72-A42FF799B21E> /usr/lib/libobjc.A.dylib
    0x7fff99bbb000 -     0x7fff99be4fff  libxpc.dylib (756.20.4) <61AB4610-9304-354C-9E9B-D57198AE9866> /usr/lib/system/libxpc.dylib
    0x7fff9ae26000 -     0x7fff9ae3cff7  libsystem_coretls.dylib (83.20.8) <75C97D88-0A63-3093-AE83-DE33EB7405CE> /usr/lib/system/libsystem_coretls.dylib
    0x7fff9aea3000 -     0x7fff9af1afe7  libcorecrypto.dylib (335.20.1) <C6BD205F-4ECE-37EE-BCAB-A76F39CDCFFA> /usr/lib/system/libcorecrypto.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 131
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=106.9M resident=0K(0%) swapped_out_or_unallocated=106.9M(100%)
Writable regions: Total=61.8M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=61.8M(100%)

                                VIRTUAL   REGION
REGION TYPE                        SIZE    COUNT (non-coalesced)
===========                     =======  =======
Activity Tracing                  2048K        2
Kernel Alloc Once                    4K        2
MALLOC                            10.2M        8
MALLOC guard page                   16K        4
Process Corpse Info               2048K        2
STACK GUARD                       56.0M        2
Stack                             8192K        2
VM_ALLOCATE                          4K        2
__DATA                            42.2M       50
__LINKEDIT                        91.3M        5
__TEXT                            15.6M       48
__UNICODE                          552K        2
shared memory                        8K        3
===========                     =======  =======
TOTAL                            227.8M      119



[dmilligan]

Sorry, I always forget about the dot.

Code Select Expand


cat ~/.mlvfs.log


[markodarko]

Is there a way to find the White Balance information so that I can input it into Resolve? Currently, "As shot" returns 2770.

Thanks,

Mark.

[newsense]

When i copy .dng's from a mounted MLV and import those dng's as a sequence into after effects using ACR the video imports but when I render I only get one frame rendered. I tried just importing the mounted .dng's and every frame rendered. Am I doing something wrong?