MLV App 1.14 - All in one MLV Video Post Processing App [Windows, Mac and Linux]

[masc]

masc: dumb question: it's not possible to force the threads to work on different image frames?

With current concept: no. But you could use MLVFS for this.

[togg]

I think you are wrong. All the detail comes out very different and shadows look just dead with this setting. It is way more than just a curve... If you look for the MLVApp look in another application, the closest should be ACR. Using Resolve for MLVApp look this is a really hard task.

You are right. So what do you suggest to replicate MLVApp look in Resolve for every image? If the base settings are not enough a 3D LUT should cover it, no?
Maybe I forgot if there has been in the past a complete explanation of what MLVApp does to contrast and colours.

[masc]

You are right. So what do you suggest to replicate MLVApp look in Resolve for every image? If the base settings are not enough a 3D LUT should cover it, no?
Maybe I forgot if there has been in the past a complete explanation of what MLVApp does to contrast and colours.

Processing in MLVApp and importing this into Resolve? I don't understand the need of replicating, when you can use the original for free.

[2blackbar]

MLVApp is not using GPU at all, i can render the same scene in resolve in minutes, and it takes hours in MLVApp.
Id love to replicate tonemapped look from MLVApp in resolve when i import DNGs, i have some presets but they arent that close
By the way, i successfully used bing chat to code and fix code recently, so what part of mlvapp code, what file do i need to feed into bing chat so it would take a look and try to add gpu rendering using ffmpeg in mlvapp ?

[masc]

Even with GPU processing, Resolve is slower for me, if it runs at all: 3h for 2min footage is normal here too. But I don't have a good GPU. Additionally 10x the time for making the footage look good plus all the artifacts it creates. 
ffmpeg doesn't render anything. MLVApp does the rendering. You need to bring all the proessing.c, raw_processing.c, as well as all related files into openCL (for best compatibility). CUDA, Metal and friends is no solution IMO. Starting point is function "getMlvProcessedFrame16(..)"

[2blackbar]

Yeh im on 3090 and was on 1080, mlvapp is still very slow, resolve has nvidia cuda acceleration for 264 and 265, its a lot faster, minutes vs hours
so the pipeline is different from resolve and this suggestion wont work ?
 

[masc]

ffmpeg on GPU would not bring much. And NVIDIA encoding doesn't work on any of my computers - probably the same for many if not most users. I also would not really recommend to render the clips to H264 or H265 if you want to edit. If you like HW encoding, try out the macOS version with AVFoundation - it brings more or less the same speed like preview without encoding (so I think Apple must do it in HW somehow). This can be faster than cDNG output. But encoding is the fastest part of creating the files. If you want to speed up MLVApp processing, you need to bring the entire RAW processing engine into GPU, not the encoding.

More tests on Apple Silicon M1, with the 3K testclip from @iaburn:
Export with my FastProxy receipt, ProRes422 AVFoundation: 8sec
Export to DNG lossless: 14sec


https://github.com/ilia3101/MLV-App/blob/master/receipts/FastProxy.marxml

[andy kh]

Yeh im on 3090 and was on 1080, mlvapp is still very slow, resolve has nvidia cuda acceleration for 264 and 265, its a lot faster, minutes vs hours

yeah its minutes vs hours. i am using a 10 year old laptop with nvidia cuda and its so fast rendering in resolve and premiere pro

[masc]

For more modern laptops it seems it has changed.

[masc]

I found a small chance for easy GPU usage in MLVApp:
"openMP target" offloading.

As we already use openMP for CPU multiprocessing, this sounds good. But a first test program tells, my system has no device for offloading. Find the test program here:
https://enccs.github.io/openmp-gpu/target/

Output for MBA M1, same for Intel MBP:
"Number of available devices 0
Running on host"

openMP >=4 is needed. Latest LLVM versions (we use already) should support this.

Maybe someone finds how to use it.

[2blackbar]

Ill try to tinker with this when gpt will be able to accept long pieces of code, with the speed ai is learning it will become better programmer than i ever could be
I can do simple edits to the code but figuring out all the branching between files in sourcecode and what needs what to work, its a long journey
I dont want to ask someone to do it especially if its not going to be useful for that person , my another goal is to also add a code to raw2mlv which would support taking external audio file into mlv container
But all of that would be solved if i would have exact reinhard tonemapping formula available in resolve

[togg]

Processing in MLVApp and importing this into Resolve? I don't understand the need of replicating, when you can use the original for free.

To have the option. It is a baked look after all, and it would be nicer to have a stronger grip on the first steps on the software where you plan to do your colour correction.

[vastunghia]

Personally I love MLV App, but I typically use it just to preview clips and discard bad ones. Then I export cDNG to be imported in DVR.

Why? Simply because in my workflow first I cut / edit, and finally grade. I don't like grading before editing, as I still don't know exactly how / where I will be using each and every clip in the final sequence (some of them may end up unused as well, so grading them would result in a waste of time btw).

I'm fully aware that I'm losing many benefits of MLV App -- and more often than not I find myself struggling in DVR to get a decent look for my shots. But after some time I'm learning to do that, so that's a price I'm willing to pay.

Now, yesterday I filmed a few clips and decided that I wanted to try the other approach -- grade first in MLV App, and then edit in DVR. I thought that it was a very small video so it definitely made sense to try.

However, I'm encountering a problem: trying to export to ProRES 4444 using Apple AVFoundation, sometimes I get no output .mov file at the end of the process. I have to repeat rendering and export over and over again, until at some point (for no apparent reason) I finally get my rendered file.

In particular, I have 7 clips, of which

• 4 went 'smooth' (success @1st try),
• 1 required 3 retries before success,
• 2 have not been exported successfully yet (tried 2/3 of times each).

I reiterate that rendering is taking place (lot of time to fill the progress bar for each clip and CPU under heavy load).

Two questions:

• Is this some sort of known bug?
• Is there anyway to understand what is going on behind the curtain? Maybe a log file?

Thanks a lot

[masc]

@vastunghia: grading before edit makes no sense. Simple ProRes422 export is faster then cDNG export. Cut with this and grade the used clips later in MLVApp (use FCPXML import), then exchange the files. This makes sense not only for small videos. Especially for multiclip videos this is extremly powerful method: you can play and edit many clips in parallel in your NLE.
There were many fixes for AVFoundation export since last official version. Latest revision runs super fast and stable (my last >1TB without any issue). But this must be compiled first, there is no official release yet. Are you on Intel or Apple Silicon?

@togg: you could plan to do the color correction and grading in MLVApp - it is made for this.

[vastunghia]

Simple ProRes422 export is faster than cDNG export. Cut with this and grade the used clips later in MLVApp (use FCPXML import), then exchange the files. This makes sense not only for small videos. Especially for multiclip videos this is extremly powerful method: you can play and edit many clips in parallel in your NLE.

Wait, wait, too fast for my poor brain power. Sounds cool anyway! So you are saying

• use MLV App to render Pro Res 422 proxies basically
• use these proxies to edit (in DVR? Or FCP?)
• export XML file from NLE back into MLV App
• use MLV App to grade
• render Pro Res 4444 masters to re-import into NLE for final touches and delivery

Is that it? Not sure I understand if DVR can export FCPXML?

There were many fixes for AVFoundation export since last official version. Latest revision runs super fast and stable (my last >1TB without any issue). But this must be compiled first, there is no official release yet. Are you on Intel or Apple Silicon?

Intel. I'm using this self-compiled version here, with code as of Jan 21:

Just sharing MLV App installer (DMG) 'nightly build' (ref. commit 3330563) for OSX x86, built with Qt6 and llvm15:

https://www.icloud.com/iclouddrive/061ffs2OUqHzzwsMapMtkx6gQ#MLVApp.3330563.llvm15.OSX

Sergio

I see now that some newer commits had some fixes for AVFoundation. Will try to build an updated version when I find the time, thanks!

[masc]

My workflow for almost all videos I do:
1. Import all MLVs in MLVApp, set CutIn/CutOut to not render parts you'll never need, render as ProRes422 with AVFoundation. Use FastProxy.marxml for fastest export, or FastProxyRCD.marxml for better but fast debayer.
2. Import all .mov into your NLE
3. Cut/Edit in NLE
4. Export FCPXML from NLE
5. Import FCPXML in MLVApp
6. Color correction/grading in MLVApp, export as ProRes4444 with AVFoundation
7. Relink the graded clips in NLE
8. Export final from NLE

I use FCPX for this. But when I implemented the FCPXML feature into MLVApp, it worked also with Davinci. Since then I did not really use it anymore for such projects. To be tested with current versions...
Edit: works exactly this way also in Davinci Resolve, with nice performance.

[vastunghia]

Very interesting, thank you masc. I'll need to take some time to try your workflow.

In the meanwhile, I'm trying to get compile environment up and running again (had to wipe all disk few weeks ago) to check if latest commits solved the problem I encountered today trying to export to ProRes 4444. Will report back asap.

[koopg]

hello,

is this doable from mlvapp ?

thanks

Sent from my SM-N975F using Tapatalk

[masc]

@koopg: "this" = what?

[vastunghia]

In the meanwhile, I'm trying to get compile environment up and running again (had to wipe all disk few weeks ago) to check if latest commits solved the problem I encountered today trying to export to ProRes 4444. Will report back asap.

Ok, compiled commit 09fd45f, I confirm now ProRes export via AVFoundation works like a charm, thank you masc!

Btw I used llvm16 just as this is the package that was brewed by default, and everything worked fine. Please find here the MacOS installer, in case anybody is looking for a recent x86 build...

I'm getting ready to try your suggested workflow, and I started doing some tests on export times.

First of all, it took 50 minutes to render my 7 (graded) 30-second clips (~95 MB/s MLV files with Danne's anamorphic preset on 5D3) recorded @24/1.001 fps -- so rendering speed @1.71 fps overall for ProRes 4444 with AVFoundation.

Tried also ProRes 422 export with AVFoundation on the same (this time ungraded) clips and obtained these results:

• FastProxy receipt (bilinear demosaic): 3.69 fps
• FastProxyRCD receipt (RCD demosaic): 3.14 fps

(For the record, I also tried 422 Proxy with ffmpeg Kostya + FastProxy receipt and obtained 2.42 fps)

Of course, DNG export is way faster -- 15.1 fps.

So, my first take-away is that the workflow you are suggesting is much more time demanding than I thought -- we need to sum the proxy ProRes 422 export and then the master ProRes 4444 export: that's 1 / ( 1 / 3.69 + 1 / 1.71 ) = 1.17 fps (1.11 with RCD) to be compared with 15.1 fps for DNG. That means 13 times longer export overall Approximately, if we are talking about 1h of footage, this translates into ~21 hours of total processing time for exporting ProRes proxies + masters, versus the 1.5 hours necessary to export DNG. Of course on my x86 Mac...

(And I guess figures would be even worse if I considered 3.5K 1x1 footage, which is my favorite setting in most occasions.)

I'm still willing to try your workflow though, as I'm aware that grading in MLV App is so much more straightforward than in DVR. Will keep studying.

Thanks

[masc]

Cool! A Qt6.5+llvm16 version. Nice. Audio works. FocusPixelMap download doesn't (was never working with 6.x for other computers than your own - whyever)

What Mac are you using? Your export is extremely slow! Is this dualiso or something?

Tested your version on my MBP2018 on Intel with a 1856x1044 clip:
- 20fps preview
- 17.3fps export speed into ProRes422 with FastProxy receipt
- 14.1fps for cDNG
(And this MBP2018 is known to be very slow for processing, because of heavy heat throttling.)

The final grade export needs its time in MLVApp, yes. But here Resolve is very slow too on all my machines (if it works at all). And your calculation is wrong, if you compare cDNG against final grade.

[vastunghia]

What Mac are you using? Your export is extremely slow! Is this dualiso or something?

2019 iMac with 3.0 GHz Core i5 running macOS 13.3.1. Clips were plain vanilla anamorphic 1x3 1808x2268, 24/1.001 fps @14bit (~95 MB/s of MLV lossless compressed data). No Dual ISO. I get 3 fps real-time preview in MLV App with no / simple / bilinear demosaic, 2 with AMaZE

Tested your version on my MBP2018 on Intel with a 1856x1044 clip[...]

My video is 2.1 times yours in terms of total pixels, I guess this may explain the different performance. Also, let's keep in mind that I'm exporting a stretched 5424x2268 video after all: so, from the point of view of AVFoundation, that's 6.3 times your video (once again in total pixel terms). Mind sharing your test clip? Would love to share mine, but it depicts my sons and I'm pretty strict on privacy matters Anyway, not so important of course.

The final grade export needs its time in MLVApp, yes. But here Resolve is very slow too on all my machines (if it works at all). And your calculation is wrong, if you compare cDNG against final grade.

Not sure I understand completely your point, sorry. Let me try and bring some order here, to check if I'm missing something at some point. So, schematically, here are the two workflows I'm trying to compare:

• Grade in DVR:
  
  • Export DNG from MLV App @15.1 fps
  • Cut in DVR
  • Grade in DVR
  • Export deliverable asset from DVR
• Grade in MLV App:
  
  • Export ProRes 442 'proxy' from MLV App @3.69 fps
  • Cut in DVR
  • Grade in MLV App
  • Export ProRes 4444 'master' from MLV App @1.71 fps
  • Export deliverable asset from DVR

I underlined all rows that make a difference between the two workflows, at least in terms of time required for overall rendering.

If the reasoning is correct, I think that my calculations are correct too. The comparison must be taken between 15.1 fps on one hand, and 1 / ( 1 / 3.69 + 1 / 1.71 ) = 1.17 fps on the other. What am I missing?

Thanks

[masc]

In 1. you still have RAW in the end, in 2. you have a nearly ready project.
--> You missed two very important underlined lines:
1.4 -> "5h" (Davinci does RAW processing and grading)
2.5 -> "5min" (Davinci just copies data)

The clip I used for M1 numbers was a 3K clip. Maybe try some non 1x3 clip, because 1x3 needs to be stretched. This needs additional time. But this time is worth it, because MLVApp uses AVIR which is by far superior to bicubic used by Resolve.

[vastunghia]

Aha, very clear thanks, noted.

I voluntarily ignored points 1.4 and 2.5 as I thought they would turn out to be similar. However I see what you mean, and I'll try to clock these two steps as well.

Maybe try some non 1x3 clip, because 1x3 needs to be stretched. This needs additional time. But this time is worth it, because MLVApp uses AVIR which is by far superior to bicubic used by Resolve.

Since I want to compare the workflows for the cases I'm more likely to encounter, I'm trying to stick to the formats I personally use most, which are 1x3 5.4K and 1x1 3.5K. Nice to know of AVIR, another point in favor of workflow 2!

[masc]

Your points 1.4 and 2.4 might also vary a lot on what you setup in those applications. I bet this will be very hard to compare, if possible at all. Even for my own projects the export speed is different for each clip, because I use other features (but the same MLV setting on camera).