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

[masc]

If you're on macOS (and maybe on Linux, not exactly sure here, as I almost never load it on Linux) you are able to create "post export scripts" which can be driven right after export. You could do a script which does this job.
In MLVApp code you can also change the ffmpeg command. That is a little complicated because there are hundreds of combined options. See function startExportPipe in MainWindow. I think it will be hard to use such a correction via ffmpeg, as you can't see what you'll get after exporting. The parameters change with zoom focal lengths, with crops, pans, etc. ... finding the correct parameters for each clip should be very very hard.

[scriptmonkey]

Thanks! I changed the code to use FFMPEG's funlens with my lens' model like this:

resizeFilter = QString( "-vf lensfun=make=Canon:model=\"Canon EOS M\":lens_model=\"Samyang 16mm f/2.0 ED AS UMC CS\":focal_length=18:aperture=8,%1scale=in_color_matrix=bt601:out_color_matrix=bt709%2%3 " )
            .arg( moireeFilter )
            .arg( hdrString )
            .arg( vidstabString )

The problem is, I cannot probably put a pipe there, so this command does the rest (filter out noise, sharpen and resize)

ffmpeg -i input.mov -f yuv4mpegpipe -pix_fmt yuv420p - | yuvdenoise -m 4,4,4 -t 4,8,8 -M 3,3,3 | ffmpeg -f yuv4mpegpipe -vcodec rawvideo -i - -vf unsharp=luma_msize_x=5:luma_msize_y=5:luma_amount=4.5,scale=w=2088:h=1104 -c:v libx264 -preset ultrafast -qp 0 -y output.mp4

I did not use export's resize option, at it would downscale everything before the geometry and noise filters. So unnecessarily large files are still written to disk. I also did not use MLV app's own sharpen, as it would be before denoise.

[masc]

Interesting. But some questions for this:
- does Lensfun understand "EOS M" + a "16mm" lens at focal length 18?
- did you check the export if distortions are correct after export?
- you used a speedbooster? This adds additional distortion. The export is really correct?
- did you use a ML setting with full sensor? At least full sensor width? Is the vertically used area exactly centered? Otherwise this also should not work, I bet.

If you use the post export scripts, you could delete files after processing. So MLVApp pipes to a first intermediate export file. Then the script is started, does the additional stuff and deletes the first file. So the needed disk space should not be much.

[scriptmonkey]

Interesting. But some questions for this:
- does Lensfun understand "EOS M" + a "16mm" lens at focal length 18?

It's my typo. Lensfun probably ignores the focal length for non-zooms entirely.

- did you check the export if distortions are correct after export?

Yes, it seemed visually perfect despite the barrel distortion in that lens being somewhat complex.

- you used a speedbooster? This adds additional distortion. The export is really correct?

I don't but the additional distortion can be handled separately. You can add to FFMPEG's -vf chain one more filter and that would add to funlens. There are a number of geometry correction filters in FFMPEG, but the subpixel quality varies.

- did you use a ML setting with full sensor? At least full sensor width? Is the vertically used area exactly centered? Otherwise this also should not work, I bet.

I used an almost 1.6-crop mode. Otherwise, lensfun has all that you asked for https://lensfun.github.io/manual/v0.3.2/el_lens.html but it seems, not all is accessible via ffmpeg. So some (likely easy) code would need to be contributed to ffmpeg.

If you use the post export scripts, you could delete files after processing. So MLVApp pipes to a first intermediate export file. Then the script is started, does the additional stuff and deletes the first file. So the needed disk space should not be much.

Yes, but I had already some problems with dying disks in the pasts

[scriptmonkey]

If only MLV app had a tab for lensfun parameters, a flow of arcane lens info would start to flow into their database. Mysteriously centered around the ef-m mount

[masc]

If someone knows how lensfun library works in detail, I'd really like to add this directly to MLVApp. Until now the docs were too hard for me

[scriptmonkey]

I do not know, but maybe the respective code from ffmpeg would help: https://github.com/FFmpeg/FFmpeg/blob/f31d0f11417067a3fc9d53085c32f4ba82b252e4/libavfilter/vf_lensfun.c#L90

[vastunghia]

Finally found the time to compile an up-to-date version for Mac Intel.

• Commit 620d7c8 (Aug 22)
• QT 6.6.0
• LLVM/OMP 17

Link here.

Ciao

[Teamsleepkid]

Can you output to prores raw? Would be kinda cool..

[masc]

Can you output to prores raw? Would be kinda cool..

No problem, if there is a library (best C/C++) which supports encoding. I did not hear about one yet.

[mlrocks]

is mlvapp intrinsically 14bit? or 12 bit?
i read somewhere resolve free version is 8 bit.

[masc]

MLVApp is 16bit, DualISO 20bit.

[a.sintes]

@mlrocks DaVinci Resolve engine (both free & studio version) works internally using 32bits float (single precision GPU float value).

[mlrocks]

MLVApp is 16bit, DualISO 20bit.

thank you, masc. probably this is why mlvapp has better color than resolve free version.

[mlrocks]

@mlrocks DaVinci Resolve engine (both free & studio version) works internally using 32bits float (single precision GPU float value).

why do someone say the free version is only 8 bit?

[masc]

thank you, masc. probably this is why mlvapp has better color than resolve free version.

Good color has also other reasons than just a bitdepth. Low bitdepth might bring banding into the footage.

[a.sintes]

why do someone say the free version is only 8 bit?

People usually say a lot of shit on the Internet
Free & Studio version of Resolve relies over the same GPU engine, Studio just got more available advanced features.
As explained by @masc, an 8-bits engine will imply very visible banding issues.

Don't get how MLVApp would have "better color" than Resolve in the end, a 14-bits integer bit depth footage fit perfectly in 32-bits float without any loss, and we're talking here about one of the most renowned color-grading software with bullet-proof color science (DaVinci Wide Gamut & ACES colorspaces etc.), so eventually the only weak point may be the RAW (DNG) debayering algorithm (personally prefer the one used by Adobe in CameraRaw) but the differences are quite indistinguishable...

[mlrocks]

People usually say a lot of shit on the Internet
Free & Studio version of Resolve relies over the same GPU engine, Studio just got more available advanced features.
As explained by @masc, an 8-bits engine will imply very visible banding issues.

Don't get how MLVApp would have "better color" than Resolve in the end, a 14-bits integer bit depth footage fit perfectly in 32-bits float without any loss, and we're talking here about one of the most renowned color-grading software with bullet-proof color science (DaVinci Wide Gamut & ACES colorspaces etc.), so eventually the only weak point may be the RAW (DNG) debayering algorithm (personally prefer the one used by Adobe in CameraRaw) but the differences are quite indistinguishable...

thanks for the good explanation.

[kob]

Is there a volume control? A mute would be great.

I have tons of clips with wind.
Can't hit play without distorting my speakers when im working.

[masc]

@kob: Uncheck Audio Output from Playback menu.

[vastunghia]

Sorry, I'm pretty sure this must have been discussed here at some point in time.

However, I compared MLV -> cDNG conversion with MLV App and MLVFS, and found out that

• MLV App exported @12.5 fps, while MLVFS exported @5.3 fps*. Q: is this difference in speed expected? Somehow I expected the opposite.
• Exported (uncompressed) DNG files are 9.4 MB when using MLV App, 10.8 MB using MLVFS. Q: what is this additional 1.4 MB per frame that MLVFS is allocating?

* which is the speed at which I could copy DNG files from the MLVFS mounted virtual drive to my physical drive.

NB: of course test export was performed starting from the same MLV file (3584 x 1500, 23.976 fps, 14 bit lossless, 119 MB/s), in both cases being exported on the same (ultra-fast NVMe) hard drive.

Thanks

S

[iaburn]

Just an open question: On the transformation menu, there are options for width and height stretch.
A height stretch of 0.33x is used for the 1x3 modes, but instead of setting 1/3rd of the height, it is actually setting 3x the width. So height stretch is not actually stretching height, but width.

Shouldn't this be fixed so it's possible to set a 3x width stretch (currently missing, maxing out at 2x), but also a 0.33x height to leave the width alone and just benefit from the lower noise and reduced aliasing by adjusting the vertical resolution?

[masc]

It was an important design decission in the old days. And it was not easy to do this magic. We can change the labels if you like: first box is for anamorphic lenses, while second box is for digital ML stretch. If you were able to stretch width at 3.0x, you're forbidden to use anamorphic lenses at the same time, while 2nd box will probably never be used. There is also no 3.0x anamorphic lens (as far as I know), so this option doesn't exist. If we would downscale the height, you would never see the additional details in 1x3 footage over 3x3. If you however want to downscale for the export, use the export settings dialog. So I think there is nothing to fix - this is as it was intended to work.

[iaburn]

It was an important design decission in the old days. And it was not easy to do this magic. We can change the labels if you like: first box is for anamorphic lenses, while second box is for digital ML stretch. If you were able to stretch width at 3.0x, you're forbidden to use anamorphic lenses at the same time, while 2nd box will probably never be used. There is also no 3.0x anamorphic lens (as far as I know), so this option doesn't exist. If we would downscale the height, you would never see the additional details in 1x3 footage over 3x3. If you however want to downscale for the export, use the export settings dialog. So I think there is nothing to fix - this is as it was intended to work.

If it was intended, then I have nothing to say.

But regarding your comment about not seeing additional details over 3x3 by scaling down, if the scaling algorithm is good, you will get added detail (oversampling), reduced noise, and of course much less aliasing artifacts than on 3x3 mode.
The problem with downscaling on export is that you never get to see the final image at a 100% while editing (final meaning scaled down), and the frame buffer is larger, so playback and editing are also slower.
For these reasons I end up always exporting to CDNG and doing all the color corrections in resolve for 1x3 clips

[masc]

Correct: you never saw the clip in the final size before export. (by standard.)
Wrong: the frame buffer is the same and the playback and editing is also the same speed. There is no reason making it faster. You must always process the entire picture first. The scaling is not that slow and viewer itself is by far faster than a video frame rate - at least on modern computers (you feel a big difference on Core2Duo). You can also drag the window to the "right size". Then you see the final size before export - if that is so important.
On encoding the entire sharpness changes anyways. Also with Davinci.