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

[rakkham]

Hi everyone.

Thanks a lot for this AMAZING app, truly.

Only concern while playing with it is the scaling factor on linux. Any idea how to force a x2 scaling factor on ubuntu ? (looking small on my 4K screen).
Thanks a lot !!!

[ilia3101]

Use this command or add it to desktop file:

Code: [Select]

QT_SCALE_FACTOR=2 ./mlvapp
You can use fractional values like 1.5, but they make the video display pixely, so 1 or 2 is best.

[masc]

Use this command or add it to desktop file:

Code: [Select]

QT_SCALE_FACTOR=2 ./mlvapp
You can use fractional values like 1.5, but they make the video display pixely, so 1 or 2 is best.

Cool! Does this transfrom each pixel to 2x2 pixels (4x the same) or does it render "sharper" like on retina displays on OSX?

[ilia3101]

It actually renders properly, looks very very nice:



though 2x is too big  for my screen so I use at 1x

[bouncyball]

Code: [Select]

QT_SCALE_FACTOR=2 ./mlvapp

Huh! I loved it! Makes it look like on retina display (which is actually IS 2x2 real pix -> 1 gui pix), very crisp!

[masc]

v1.5 is out:
- Optimized demosaicing results for AMaZE and IGV
- Changed 0.33x vertical resizing from downscaling to upscaling
- Added AHD demosaicing algorithm
- Added "Create all MAPP files" action for all clips in session
- Added uncompressed avi with pix-fmt bgr24
- Some bug fixes and some minor changes
Have fun!

[togg]

first download is mine! thanks

[Cipolippo]

Thanks  thanks..Please add support for dcp profile... 

[masc]

Thanks  thanks..Please add support for dcp profile... 

DCP = DNG camera profile. We are working on MLV files. Input should be DNG, generated by Adobe Tools (in order to get correct output). Support is not possible.

[70MM13]

excellent update!
the enhancements and additions to the demosaicing are very nice.

someone mentioned running multiple instances to speed up rendering jobs.  would it be possible to add some kind of (automated?) job control to do this, perhaps with a simple option to choose how many to spawn, unless it is possible to autodetect the number of threads available on all platforms?

the results i'm getting with the linear setup are so good that i now prefer mlvapp to resolve!

need...faster...rendering...

[masc]

excellent update!
the enhancements and additions to the demosaicing are very nice.

someone mentioned running multiple instances to speed up rendering jobs.  would it be possible to add some kind of (automated?) job control to do this, perhaps with a simple option to choose how many to spawn, unless it is possible to autodetect the number of threads available on all platforms?

the results i'm getting with the linear setup are so good that i now prefer mlvapp to resolve!

need...faster...rendering...

The easy solution you wrote here. Create multiple instances of the app and export with them.
The harder solution is writing a new MLVApp - or at least rewrite a big part of it. And this might only help on systems with many processors. On my 2 Core or 4 Core I already have 100% activity when exporting.

[70MM13]

sorry, i guess i didn't clearly state that i was thinking about a job control utility, as in a separate applet that would call x number of mlvapps to do a batch render.

someone wrote something like this for blender long ago...

[masc]

I understand what you mean. Someone had this idea already a year ago here in the forum. But here it would really mean a very big redesign. And all we did until now regarding multithreading could be deleted again.

[70MM13]

ok then, how about this?

a function to automagically generate x number of partial sessions from the one currently loaded to facilitate doing multiple instances manually.

it can be tedious to do this by hand, especially with a long shot list.

it is not a hassle if you are only doing 2 incarnations, in fact it is nice and easy.  just load the same session and choose the first or second half of the list.  but what if you are doing 8? 16? 32? (thread ripper users)

just thinking out loud.

even doing 2 by hand cuts the time in half, but that threadripper user would be sad to be using 2 out of 32

[togg]

Curious to see some debayer comparison if someone wants to do it!

For me one of the feature still missing is an automatically skip problematic frames. Yesterday I had another episode like that that stopped the export, a black frame at the end of one clip when the camera stopped because of a full CF. I had forgot about it and MLV stopped during export. Would be nice to have an option to have this skipped automatically, could be very usefull imho.

[masc]

Curious to see some debayer comparison if someone wants to do it!

In our wiki there is a comparison. And there are many many comparisons out in the net. But note that for each clip the result might be very different! There is no "best debayer". It depends on situation.

[ilia3101]

There is no "best debayer"

But generally AMaZE...

[DeafEyeJedi]

The easy solution you wrote here. Create multiple instances of the app and export with them.

Incidentally this may not be ideal but I've made two extra (three was too much for my 2012 MBP 2.6 GHz i7 16GB to handle) copies of MLV Apps on the desktop and can 'multithread' by running all three at once. Just beware of your machine singing its praises! 

...one of the feature still missing is an automatically skip problematic frames.....Would be nice to have an option to have this skipped automatically, could be very usefull imho.

+10

Basically my recent experience w 1.4 went from an ETA of 96 hours countdown for 1.1 TB worth of MLV's to a mere 9 days and still counting... Waking up in the mornings every now and then seeing MLV App had crashed overnight or at least until to the next day if not second. This app is still so fkin' good that I want to keep it going regardless of this gruesome dreadful time consuming never-ending roundtrips of horror. 

I know, I know... technically speaking this isn't up to par for paid gigs (just yet) but hey I forced myself to go 100% on MLV App just for this small project of mine. Very happy with the grade and noise reduction is indeed quite impressive. Even for footage shot in ISO 6400 without using DF Avg. No need for Neat. 

Still haven't wrapped my head around the DF feature within MLV App yet. Will get to that point once I am done with this project and thank you all for your continuous support!

[Danne]

...one of the feature still missing is an automatically skip problematic frames.....Would be nice to have an option to have this skipped automatically, could be very usefull imho.

Is the problems happens due to mlv_dump code it should be possible to insert the "relaxed" mode skipping files right bouncyball?
If in ffmpeg the syntax could be changed to pass on missing files I believe.
Who knows where the issue lays?

Wildcard pass in ffmpeg?

Code: [Select]

ffmpeg -f image2 -i %*.jpg out.mov /*example*/

[masc]

Incidentally this may not be ideal but I've made two extra (three was too much for my 2012 MBP 2.6 GHz i7 16GB to handle) copies of MLV Apps on the desktop and can 'multithread' by running all three at once. Just beware of your machine singing its praises! 

This is exactly the reason why I won't do it. Multiprocessing of inner processing is fighting against all other programs running at the same time.

Basically my recent experience w 1.4 went from an ETA of 96 hours countdown for 1.1 TB worth of MLV's to a mere 9 days and still counting...

OMG! What crazy features are you using at the same time (dualiso?)?! The longest rendering time for 500GB was ~10hours for me (on my 8 years old i5)!


The problem aborting at corrupted frames was discussed many times here already. Mostly a corrupted file can't be handled for roundtrips, audio does not fit to video, linking does not work, etc. ... these are only some of the reasons why bouncyball and I decided to aborted export for corrupted clips. If just the last frame is currupted, this might be a a special case - but even than it leads very often to linking issues when working with Resolve or FCPX.

[Danne]

How about inserting a black frame for every detected corrupted frame?
General question. Is a corrupted frame in one MLV file aborting the whole batch process in MLV app? If not I could live without the export of corrupted files although cool if it would work with black frames.

On a side note. I tried multi rendering on dual iso files since those are really slow to process. Flickering occured so had to run processing with only one copy of Mlv App to get comsistent results. Strange. They shouldn´t interfere with each other?

[Lars Steenhoff]

There are 18 core macs out there, are you sure you want to limit to just one core?
Seems like a missing performance oppertunity.

Probably I don't understand how it works

[ilia3101]

The problem aborting at corrupted frames was discussed many times here already. Mostly a corrupted file can't be handled for roundtrips, audio does not fit to video, linking does not work, etc. ... these are only some of the reasons why bouncyball and I decided to aborted export for corrupted clips. If just the last frame is currupted, this might be a a special case - but even than it leads very often to linking issues when working with Resolve or FCPX.

For some reason I have never had a corrupted file in MLV App, so I don't have experience, but maybe export should only abort for that one clip that is corrupted.

Maybe put a warning somewhere...

(Our what danne said too)

[IDA_ML]

In my opinion, the best way to handle corrupt frames would be to have the algorithm detect corrupt frame number N and replace it with another frame which is interpolated between frames N-1 and N+1.  In that way, the transition would barely be noticeable and sound would not be affected.  Would that be possible to implement or am I dreaming too much?  What do you think, Masc?

[togg]

How about inserting a black frame for every detected corrupted frame?
General question. Is a corrupted frame in one MLV file aborting the whole batch process in MLV app? If not I could live without the export of corrupted files although cool if it would work with black frames.

That is exactly it. It stops the whole batch process, needs a manual interaction. And yes black frames would be the perfect solution, especially because with magic lantern mlv one black frame at the end happens very often for a multitude of reasons.