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

Started by ilia3101, July 08, 2017, 10:19:19 PM

Previous topic - Next topic

0 Members and 4 Guests are viewing this topic.

theBilalFakhouri

Quote from: masc on September 13, 2019, 01:20:10 PM
If (with same settings) bilinear brings 100% CPU usage and AMaZE does not, you're right: it can only be something related to debayer algorithms.

Yeah Bilinear Exporting gives 37 Seconds in both versions and with 90% CPU usage in my system .

masc

5D3.113 | EOSM.202

theBilalFakhouri

Quote from: masc on September 13, 2019, 09:51:47 PM
You can try out now. Commited.

It's Working great , Now I can get 14 FPS AMaZE playback , and the clip took 45 Seconds for exporting , Awesome , Reinhard 3/5 is really nice too , it should be as default setting , great work!

rev787

When using Fix Focus Dots with dual iso, there's slight color shift, eventually causing flicker. I'm on 1.8. Shall I use chroma smooth instead of fix focus dots when dealing with dual iso files?
sample mlv: https://mega.nz/#!tt4zgKwQ!yfkUgUorBx_ueCxnXy1G28VaLQ75UMj0di3s4JFYaGQ
EOS M 2.5k, Sep 13 build. The first frame has stronger color shift.

masc

Yepp... have seen this color shift since a very long time. One of the reasons why I mostly don't like to use chroma smooth. If someone knows how this algorithm works... maybe there is some small bug or it is the way it has to look - I have no idea. All I found: when using chroma smooth, set RAW black level +1 or -1 to default value and the shift disappears.
For topic focus pixels: better using a correct map instead of blurring the whole picture with chroma smooth. Chroma smooth is kind of "last resort" if nothing else helps.
5D3.113 | EOSM.202

DeafEyeJedi

Quote from: masc on September 15, 2019, 09:56:39 AM
Yepp... have seen this color shift since a very long time. One of the reasons why I mostly don't like to use chroma smooth. If someone knows how this algorithm works... maybe there is some small bug or it is the way it has to look

Agreed. It's been a while that we have seen one without the flickering. I just tried this the other day and can confirm the mild flickering. No deal breaker though as long as you don't push them too hard in post.

Quote from: masc on September 15, 2019, 09:56:39 AM
- I have no idea. All I found: when using chroma smooth, set RAW black level +1 or -1 to default value and the shift disappears.

Ah, good to know. I will definitely try this trick out. Thanks for sharing!


Quote from: masc on September 15, 2019, 09:56:39 AM
For topic focus pixels: better using a correct map instead of blurring the whole picture with chroma smooth. Chroma smooth is kind of "last resort" if nothing else helps.

Absolutely. Avoid CS whenever possible unless needed. As we should.
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

Danne

Hehe, your wife is a goid dancer deafeyejedi :).
Cs 3x3. Nothing wrong with sharpness there. Slight color shift though towards green.

masc

Quote from: Danne on September 17, 2019, 09:03:41 PM
Cs 3x3. Nothing wrong with sharpness there. Slight color shift though towards green.
Sharpness is little less, especially with 1080p footage. For the green color shift try out RAW black level... +-1 fixes this - whyever.
5D3.113 | EOSM.202

Danne

Hm, I think the reduced bitdepth is causing it to become greener. 14bit seems handling this issue better.
Changing black level don´t really work over here.

theBilalFakhouri

How MLVApp exporting works is by processing frame 1 then frame 2 then frame 3 . . . to the last frame , can we export multiple frames in the same time (in this case every core or maybe thread will work on one frame)  to speed up the process a lot more ? a.k.a Multiprocessing,

Yesterday I was looking for solutions to speed Up After Effects rendering (After Effects isn't getting benefits from all cores and threads it's only use one core heavily and all the other cores are very close to idle ) , the solution was a tool and script called Render Boss the way how it works is by exporting multiple frames in the same time into a (e.g. png sequence) , every frame uses a core , if core 1 is working on exporting frame 1 , the core 2 will skip frame 1 and will work on frame 2 . . etc , we can't export .mov directly in this way , first of all we should export as sequence to know which frame is exporting now and skip it and work on another frame on another core , then if we want single video we take these sequence and process it to a .mov file .

Let's say I have MLV clip with 1000 Frames:
Now I can test this in MLVApp , it's like opening MLVApp multiple times (Let's say 2 MLVApps are running) and splitting the chosen MLV file to 2 copies , every copy have 500 Frames (I used cut In & Cut Out) first MLV now have the first 500 Frames from the original one , second MLV have the frames from 501 to 1000 and so on . .

Results:
Exporting original 1000 Frames MLV file in one running MLVApp took 1 Minute               (CPU was 59%)
Exporting splitted 500 Frames for each MLV file running into 2 MLVApp took 43 Seconds (CPU was 97%)
I was exporting to Prores 444 (FFmpeg encoding was working) , Not really bad and maybe there is a room for getting better results if that was originally in single MLVApp (or if encode these frames after processing all of it).

Processing Dual ISO in my system takes 5% CPU exporting to CinemaDNG (1280x1920 clip) , I can run 20 MLVApps to get 100% CPU (I tried 6 MLVApps and it was 30% CPU , 6 times faster) , so it will be x20 Faster Dual ISO if it was 20 MLVApps are running . Same for Shadows/Highlights it was uses 15% in single MLVApp (without ffmpeg encoding) , with Multiprocessing it will be x5 to x6 faster on my system.

It's very big deal !

Try it on your system if the CPU wasn't 100% when exporting , you don't have to split MLV file , just set cut In & Cut Out points (the first MLVApp set it from frame 1 to 250 , the second MLVApp set it from frame 251 to frame 500 and so on depending on your MLV clip then start exporting for each MLVApp with same settings).

masc

This idea is so old as MLVApp itself. One of the very first versions was working this way. Then we decided to render a frame with multiple threads - as far as possible. Both strategies will fight against each other in terms of CPU power, and will partially lock themselfs when being called from one app. This is why the "multiple frames at one time" strategy was removed. There were many thoughts behind that. I can't and won't write down all that again. You'll find it here in the thread and on github (about 1.5 years ago).

The advantage of the current strategy is fast(er) playback. The disadvantage is, that if a algorithm (part of processing pipeline) can only be rendered single threaded, you'll waste your power. We know that. The current Dual-ISO algorithm is just single threaded. If someone likes, you're welcome to implement a multi-threaded version of it. When we tried in past, we failed.

If it helps having multiple instances of MLVApp, this is by far the easiest way to minimize the rendering time. All other solution would mean to re-implement processing and piping nealry from scratch.
5D3.113 | EOSM.202

Danne

Quote from: theBilalFakhouri on September 18, 2019, 11:37:58 AM
Yesterday I was looking for solutions to speed Up After Effects rendering (After Effects isn't getting benefits from all cores and threads it's only use one core heavily and all the other cores are very close to idle ) , the solution was a tool and script called Render Boss the way how it works is by exporting multiple frames in the same time into a (e.g. png sequence) , every frame uses a core , if core 1 is working on exporting frame 1 , the core 2 will skip frame 1 and will work on frame 2 . . etc , we can't export .mov directly in this way , first of all we should export as sequence to know which frame is exporting now and skip it and work on another frame on another core , then if we want single video we take these sequence and process it to a .mov file .
aerender is included with after effects and it´s quite interesting that you can build more efficient workflows with this than running from gui. But I guess architecture in ae isn´t flexible enough to work more efficiently. In mac based Switch I do multiprocessing(four exports) in parallell going through aerender working with a base ae project template. This make exports worth the time in ae whereas the one by one export from gui way to slow.
Off topic  :P

theBilalFakhouri

@masc

So my ideas were stolen before I thought about it for the last 1.5 years ago :P

Isn't it easier to run second MLVApp in Background and make communication between the Main MLVApp and the Background copies (Instead of doing it manually in my case , I mean split the work between MLVApps copies from XX frame to XX frame) ? for good Multiprocessing and Multithreading at the same time without re-coding algorithms , Or you just want good algorithms for these things for not complicate the things more ? Not sure I am not a coder.

Another Question about only single threaded stages in the pipeline , These single threaded stages must be single threaded ? or more knowledge required to get it working multithreaded properly ? . .
Thanks

Quote from: Danne link=topic=200quote author=Danne link=topic=20025.msg220704#msg220704 date=1568804000]
In mac based Switch I do multiprocessing(four exports) in parallell going through aerender working with a base ae project template. This make exports worth the time in ae whereas the one by one export from gui way to slow.

Aha , Cool things :D I will take a look about aerender

Quote from: Danne on September 18, 2019, 12:53:20 PM
Off topic  :P
We should stop talking here :P

masc

Quote from: theBilalFakhouri on September 18, 2019, 03:38:58 PM
Isn't it easier to run second MLVApp in Background and make communication between the Main MLVApp and the Background copies (Instead of doing it manually in my case , I mean split the work between MLVApps copies from XX frame to XX frame) ? for good Multiprocessing and Multithreading at the same time without re-coding algorithms , Or you just want good algorithms for these things for not complicate the things more ? Not sure I am not a coder.
This is more or less what we did in past. Not with MLVApp copies, but with copies of pipelines. Partially you must allow access only to one single pipeline to certain memory spaces (e.g. file reading, parameter settings,...), so you'll have to lock and unlock some sections, this makes the game very difficult. Hard to explain in an easy way for non-SW-developpers. It is way easier if the user runs multiple instances of a program manually.

Quote from: theBilalFakhouri on September 18, 2019, 03:38:58 PM
Another Question about only single threaded stages in the pipeline , These single threaded stages must be single threaded ? or more knowledge required to get it working multithreaded properly ? . .
These are algorithms implemented for being single threaded. Examples are Dual-ISO, Recursive Bilateral Filter "RBF" (for highlights, shadows, clarity and denoiser). Maybe it is possible to get it multithreaded somehow - but not with our existing code. So someone should understand how that has to work and write a own multithreaded implementation.

Edit: especially for the RBF filter it would bring a lot of speed. I found this algorithm here: https://github.com/Fig1024/OP_RBF There are ways for getting it faster (see diagrams). Problem: the algorithm is for RGB24 (3x8bit) by standard. With some effort I managed to get it to RGB48 (3x16bit) with some changes in the code. But this luck I just had for the simplest "standard/original implementation", not for the SSE and AVX versions. And - really - I have no idea at all how that works.
5D3.113 | EOSM.202

DeafEyeJedi

Quite frankly, I've tried running MLV Apps (in multiple copies) in the past and utilize them all to try to save the extra 20-30+ minutes or so. CPU was definitely up there.

But man, I could literally cook fried eggs on the Mac while it was singing its' praises.  It should be an user's choice rather than MLV App's default. :o

Quote from: Danne on September 18, 2019, 12:53:20 PM
..In mac based Switch I do multiprocessing(four exports) in parallel going through aerender working with a base ae project template. This makes exports worth the time in ae whereas the one by one export from gui way to slow
Off topic  :P

Ah, thee good ole' days of Switch. Such fond memories and yet I still use it for Dual-ISO CR2's, DF averaging on MLV's (I still can't figure out how to use the DF feature on this app) :-\

Anyway, I've just compiled v1.9 on my OSX. I will give this one a test run. Thanks, @Ilia3101 & @masc for the updates as usual!
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

masc

For all users who were waiting for so long... v1.9 is out:
- Processing upgrade: tonemapping function, gamut and gamma can now be set individually
- Log profiles now have correct gamuts, in addition to the curve. Can match your Alexa very accurately.
- Added multithreaded AVIR rescaling for AVFoundation export, single frame PNG export and viewer
- Added sharpen mask slider (sharpen just edges)
- Added "move to trash" for MLV clips + MAPP files in session
- Added a dialog which shows all installed and the currently used focus pixel map(s)
- Added a new tonemap function "Reinhard 3/5"
- Space button on last frame starts playback from beginning
- Some bug fixes and some minor changes
5D3.113 | EOSM.202


ZEEK

EOS M

theBilalFakhouri

Sound playback isn't working in MLVApp 1.9 unfortunately on Windows (I tried both 32 & 64 bit) , maybe there is a problem with compiling

Quentin


masc

Thanks guys.

Quote from: theBilalFakhouri on September 18, 2019, 11:59:00 PM
Sound playback isn't working in MLVApp 1.9 unfortunately on Windows (I tried both 32 & 64 bit) , maybe there is a problem with compiling
Sound works fine over here on both Win versions. Have you enabled output? We changed absolutely nothing for sound playback, toolchain for Win32 version is also identical to v1.8.
5D3.113 | EOSM.202

jimiz

win7 (64) 
with 1.9 x32 work good
with 1.9 x64  any MLV import, no video compare..and crash program... (long last 1.8 was all ok)

5D3-123

masc

Quote from: jimiz on September 19, 2019, 11:12:20 AM
win7 (64) 
with 1.9 x64  any MLV import, no video compare..and crash program... (long last 1.8 was all ok)
Could you uplaod a short MLV sample? Can't get any crash here. What do you mean with "video compare"?
5D3.113 | EOSM.202

jimiz

with ANY   MLV...also what you found here in this topic ....
program start and seem working, you select on menu Import mlv....and 2 seconds later program crash and close.
no video" compare":   in this 2 seconds no video appears  !!!

same MLV with 32bit version,  work with any problem.

the 1.8 and earlier (x64) works!
I'v see that this time with the 1.9 there are a lot of new files inside program DIR ... meaby i need something extra on my WIN7 be installed?  drivers and video they are all up to date



5D3-123

Cipolippo

win10 (64) 
Mlv app 1.9 (64bit) Crash  ??? ;)

Mlv app 1.9 (32bit) works