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

[Luther]

@Luther: What exactly is this? You quoted my post from the post with the topic order sharpening/denoising. How is it related? Looks like it has to do with profiles somehow...

Ah, sorry @masc. It was about the suggestions I gave in the post that you replied ("flexible" and perceptual curves to MLVApp). I think these are very useful, but I've only seem this on rawtherapee. Would be great if the RT code could be adapted to MLVApp. So I linked above part of this code.

[theBilalFakhouri]

I compiled latest MLVApp from source today it's amazing thanks @masc @Ilia3101 , but noticed slower preview with same file (1736x976 11-bit lossless 23.976 FPS ) , using Bilinear debayer I got 21FPS in MLVApp 1.8 from download page and only 16FPS from the compiled version with the latest changes , using AMAZE I got 5FPS with latest changes version and 16FPS from MLVApp 1.0 , can someone confirm that slower speed ? or the problem in my compiled version maybe ?

[Danne]

Are you running openmp? Mac or windows?

[ilia3101]

Wow 16FPS amaze was possible in 1.0 really? And as of which version has it slowed down most significantly?

i would like to bring that back if possible. whats ur pc specs

[theBilalFakhouri]

Are you running openmp? Mac or windows?

I am on Windows , How to run openmp ? I did a clean install of qt version 5.9.8 yesterday with MinGW 32 bit compiler then I opened MLVApp.pro and Pressed play button to start compiling , is there something else should I do ?

Wow 16FPS amaze was possible in 1.0 really?

i would like to bring that back if possible. whats ur pc specs

Yes it's amazing

I did a huge upgrade yesterday , an AMD Ryzen 3900x CPU ...

Full specs:

Code: [Select]

AMD Ryzen 3900x
Asus ROG x570 Gaming-F
64GB of RAM DDR4 3000MHz
RTX 2080 SUPER
1 TB NMVe SSD M.2
4 TB HDD

...  MLVApp uses only 30% Overall when exporting  (All threads are used) , a MLV file 1736x976 @ 23.976 FPS 1:15 minute long took 3:36 minutes to export with AMAZE debayer and High H.264 preset , I am expecting about 1:20 Minute exporting time when the CPU load is 90% , if it was 100% Load --> a bit More than real-time AMAZE debayering and exporting .

I tried also previewing MLV file in MLVApp 1.0 (I can select AMAZE for preview , please get it back ) Same clip above I got 16 FPS and with cached mode it's real-time AMAZE Wiiith 17GB of RAM Uses , Also AMAZE playback only uses 30% CPU , a clip ( shot on 1736x738 @23.976 FPS) has almost real-time AMAZE preview @ 20 FPS .

Of course the clips above were Lossless , but With uncompressed file (1736x976 @ 23.976 FPS 10.7 Seconds long) took 11.38 Seconds to process , 21 FPS playback with AMAZE (It was using 38% CPU)

So why it's limited to 30% , on i5-4210U it always was 100%

[theBilalFakhouri]

i would like to bring that back if possible.

Done. Additionally I added a option to prevent MLVApp from switching between viewer-debayer and playback-debayer.

@masc did it already - Thanks @masc

And as of which version has it slowed down most significantly?

I compiled MLVApp today with latest changes , it was slow overall for playback (That's what I tested) , I think MLVApp 1.8 from download page also have same playback speed as MLVApp 1.0 with AMAZE debayer  but we couldn't select AMAZE as Playback since MLVApp 1.1 or 1.2

[ilia3101]

@bilal thanks.

Maybe the new scaling has something to do with speed? @masc

[masc]

Maybe the new scaling has something to do with speed? @masc

If it is used (e.g. clip has to be stretched), yes, if not, then not - depends on the opened file. But you can switch it off from Playback menu.
Here I get between v1.1 and latest revision: 15 vs 13 fps (bilinear) and 4 vs 3 fps (AMaZE), for a 1856x1044 file on a i5 dual core OSX. I get the same numbers for same versions and clip on i7 running Windows. But I think that is okay, if you see how much more functions need to be calculated in latest revision vs. 1.1.

I am on Windows , How to run openmp ?

MinGW should bring automatically openMP on Windows.

Did you run "AMaZE cached" in v1.0?

[ilia3101]

I think speed improvement will be one of next things on my list.

[theBilalFakhouri]

If it is used, yes, if not, then not - depends on the opened file.

If you mean "Better resizer for Viewer" It doesn't affect the performance for me in both cases (ON/OFF) .

Did you run AMaZE cached in v1.0?

I got real-time Playback when AMaZE cached selected , and 16FPS when using AMaZE only .

Forget about AMaZE right now and MLVApp 1.0 ,

Using Bilinear debayer:
1- MLVApp 1.8 from download page gives 21 FPS playback
2- a compiled version of MLVApp 1.8 with latest changes "Master branch" gives only 16 FPS , Same settings same file same everything  (The new changes made it slower ? ) , could try to playback a file and see is there a difference in playback speed between MLVApp 1.8 from download page and a compiled version with the latest changes ?

[masc]

From v1.8 to current revision I don't see any speed difference here, at least with default settings.

[theBilalFakhouri]

Okay now it's working as it should work maybe the problem was when compiling , Bilinear is giving now 21 FPS with latest changes , but AMaZE is only giving 6 FPS playback , in MLVApp 1.0 it's 16 FPS with no cached version used.

Anyway I will wait for the new release to do more tests.

[masc]

I agree with all of your test result, because it is more or less the same I see here on my iMac2011... but 16fps for AMaZE (uncached) - I never saw this, no matter what version or computer or OS. And I can't imagine how AMaZE can be so fast, because the realization did not change.

[Danne]

Trying to delete mlv files from the session bar and keep getting this:

 



EDIT: Think it´s because of character "ö". Could you check for å,ä,ö?

[masc]

Thanks Danne. Reproduced. Will have a look.

Edit: fixed.

[MagicPhotoEvents]

Hello,

I have installed MLVApp on my Ubuntu 18.04 computer:
Linux version 4.15.0-58-generic (buildd@lcy01-amd64-013) (gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)) #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019

The MLVApp launch then I choose the "Import MLV" command from the "File" submenu.

When I have choose the mlv video file and I clic on the "Open" bouton of the dialog, I have the error:
(mlvapp:7147): Gtk-WARNING **: 08:53:36.023: Theme file for DMZ-Black has no directories
Gtk-Message: 08:53:36.149: GtkDialog mapped without a transient parent. This is discouraged.
Instruction non permise (core dumped)

Can somebody help me please ?

Thank's for your help

Olivier

[Danne]

Thanks Danne. Reproduced. Will have a look.

Edit: fixed.

Great!

[theBilalFakhouri]

More Tests:
I used MLVApp 1.0 & 1.8 versions from download page:

Same Clip , Same settings , Exporting to Apple Prores 444 , 30 Seconds Clip , 23.976 FPS , 1736x976 , 14-bit Lossless

MLVApp 1.0 :
Bilinear Exporting took 28 Seconds
AMaZE Exporting took 42 Seconds  (was Using 60% CPU)

MLVApp 1.8:
Bilinear Exporting took 36 Seconds
AMaZE Exporting took 1:23 Minutes (was Using 34% CPU)

**Dual ISO , 6 Seconds Clip , 1736x868 , 14-bit Lossless , 23.976 FPS , Exporting to Apple Prores 444:
MLVApp 1.0 : AMaZE Exporting took 31 Seconds     (was Using 46% CPU)
MLVApp 1.8 : AMaZE Exporting took 1:28 Minutes   (was Using 9% CPU)
It's okay for Dual ISO I remember some problems happened when we were using openmp for Dual ISO and after then bouncyball disabled it from source. **

If your system was always 100% CPU in both MLVApp versions I don't think you will see a difference , you need a faster CPU than MLVApp needs for these versions , we should look back at what made MLVApp slower (Color Matrices doesn't affect the performance)

I will try the other versions of MLVApp to find out what the exact version the slow appeared . .

Edit:
MLVApp 1.4 Okay not affected
MLVApp 1.6 Okay not affected
MLVApp 1.7 Okay not affected : Same 30 Seconds clip above : AMaZE Exporting took 42 Seconds (was Using 60% CPU)

The slow speed happened in the last release only which is 1.8 (bad commit affected the speed ? ) , switching back to 1.7 for the speed (I think MLVApp 1.7 will give 16 FPS AMaZE playback in my case , @masc I will shot a video MLVApp showing 16 FPS AMaZE without caching).

[Danne]

Same Clip , Same settings , Exporting to Apple Prores 444 , 30 Seconds Clip , 23.976 FPS , 1736x976 , 14-bit Lossless

Could be related to apple prores. Did you test ffmpeg kostya or similar? There were a few updates around scaling and export(multithreading?) concerning apple prores specifically.

[masc]

Can you share your settings (receipt)? If you e.g. used Clarity / Highlights / Shadows I know what is going on (but this came in 1.7) AMaZE is so a little part in the overall system, it won't depend on just this. AMaZE itself always uses 100%. So if you see low values here, another processing part is pulling it down. This only can be a single-threaded algorithm.

@masc I will shot a video MLVApp showing 16 FPS AMaZE without caching)

If you rechecked, no need for it I trust you...

[theBilalFakhouri]

Could be related to apple prores. Did you test ffmpeg kostya or similar? There were a few updates around scaling and export(multithreading?) concerning apple prores specifically.

I don't think it's related , I used ffmpeg kostya in all cases for Prores 444 , using ffmpeg Anatolyi gives the same results . .

Tried to exporting to H.264 High preset .mov same 30 seconds clip:
MLVApp 1.7 : took 43 Seconds 50% CPU
MLVApp 1.8 : took 1:22 Minuets 28% CPU

[masc]

@MagicPhotoEvents: looks like a linux theme problem. Have you modded your Ubuntu somehow? Never seen this, but

Code: [Select]

(mlvapp:7147): Gtk-WARNING **: 08:53:36.023: Theme file for DMZ-Black has no directories
Gtk-Message: 08:53:36.149: GtkDialog mapped without a transient parent. This is discouraged.makes me think so. Does the official release (AppImage) create the same error?

[theBilalFakhouri]

Can you share your settings (receipt)? If you e.g. used Clarity / Highlights / Shadows I know what is going on (but this came in 1.7) AMaZE is so a little part in the overall system, it won't depend on just this. AMaZE itself always uses 100%. So if you see low values here, another processing part is pulling it down. This only can be a single-threaded algorithm.

From the description:
"
MLVApp 1.8 Export started at 1:02 and Ended in 2:25
It took 1 Minute and 23 Seconds

MLVApp 1.7 Export started at 3:34 and Ended in 4:17
it took 43 Seconds
"

If you rechecked, no need for it I trust you...

Thanks , I have Teamviewer if you want

[masc]

Thank you, theBilalFakhouri. So you just used default settings. 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.
And I think I found it. The only thing changed between 1.7 and 1.8 in terms of debayer was wb-conversion for AMaZE, IGV, AHD and LMMSE. These algorithms became slow while others stayed fast. When watching these two wb-conversion functions, there is an openMP call per function. I exchanged it and got 100% CPU usage instead of 51% on Windows on an i7. I'll do some more tests later and will commit then. Having just 2 or 4 threads the difference is close to 0, while having 8 threads (and surely more) it gets visible.

[theBilalFakhouri]

So you just used default settings.

Oh yess that's what I was trying to tell with "Same settings" , I will wait for your next commit , Thanks!