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

[masc]

I asked this before , is there a way to export with our own h264 quality maybe with some command line ?

Would be nice to be able to choose the --crf value and -preset option. +1

+1

-1
Commandline is no good idea. One single wrong or unexpected symbol brings the whole thing to crash. If you like other options, you could change the numbers in source code and compile. This is the simplest, fastest and safest way to get what you want.
Changing parameter elements dynamically in dependency to codec is extremely overkill IMO.

[Danne]

Agree about overkill. Search for libx264 -preset or libx265 -preset in source code and start experimenting changing bitrate, compiling.

[DeafEyeJedi]

Ah, good to know. Thanks for clarifying @masc & @Danne!

Either way it seems perfect as is for H264 exports especially for online viewing purpose.

[Luther]

-1
Commandline is no good idea. One single wrong or unexpected symbol brings the whole thing to crash. If you like other options, you could change the numbers in source code and compile. This is the simplest, fastest and safest way to get what you want.
Changing parameter elements dynamically in dependency to codec is extremely overkill IMO.

And who said anything about command line imput? I agree that parsing can go wrong, but the first suggestion I agreed was to add a Qt box to select some common options in h.264. No parsing issues, it's just hardcoded. Particularly the CRF value (from ~18 to ~34) and the Preset option (from 'fast' to 'slow') would be useful. Also, for h.264, ffmpeg has NVENC, which speeds up the encoding using GPU...

I don't even use H.264 while on MLVApp, I export in ProRes. But, these options would be nice for people that want faster exporting times or just a highly-compressed preview of some scene (a "daily", as some people call it).

[masc]

And who said anything about command line imput?

-->

I asked this before , is there a way to export with our own h264 quality maybe with some command line ?

---------------

...but the first suggestion I agreed was to add a Qt box to select some common options in h.264. No parsing issues, it's just hardcoded. ...

No, it is not hardcoded. It is dynamic, because it must only be visible for H.264 & H.265.
-->

Changing parameter elements dynamically in dependency to codec is extremely overkill IMO.

So I suggested:

If you like other options, you could change the numbers in source code and compile.

---------------

Also, for h.264, ffmpeg has NVENC, which speeds up the encoding using GPU...

Yapp, that is right. But you need to compile a special ffmpeg version in order to use it. And I can't test or try, because I don't own a supported GPU. If someone else likes to try out: please post results. If we can detect those supported graphic cards somehow, and if we can setup our GUI dynamically with that, it should be easy to add this option.

[cmh]

MLV-App's ffmpeg binary for Windows is already compiled with --enable-nvenc. I own an nVidia card and I could install some distros real quick if further testing is needed.
As for Luther's suggestion, he's probably thinking of a simple slider for Constant Quality RF. No parsing required.
I don't care about any of those features personally because there's no way to edit in MLV-App efficiently, so Prores it is.

Anyway, ffmpeg -h encoder=h264_nvenc and ffmpeg -h encoder=hevc_nvenc gives me those outputs on Windows. I omitted the whole AVOptions part but here's the whole output https://pastebin.com/n13ueWaE

PS C:\Users\Windows\Desktop\MLV.App.v1.9.Win64.static> .\ffmpeg.exe -h encoder=h264_nvenc
ffmpeg version N-93580-g036b4b0f85 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 8.3.1 (GCC) 20190414
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt
Encoder h264_nvenc [NVIDIA NVENC H.264 encoder]:
    General capabilities: delay hardware
    Threading capabilities: none
    Supported pixel formats: yuv420p nv12 p010le yuv444p p016le yuv444p16le bgr0 rgb0 cuda d3d11

PS C:\Users\Windows\Desktop\MLV.App.v1.9.Win64.static> .\ffmpeg.exe -h encoder=hevc_nvenc
ffmpeg version N-93580-g036b4b0f85 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 8.3.1 (GCC) 20190414
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt
Encoder hevc_nvenc [NVIDIA NVENC hevc encoder]:
    General capabilities: delay hardware
    Threading capabilities: none
    Supported pixel formats: yuv420p nv12 p010le yuv444p p016le yuv444p16le bgr0 rgb0 cuda d3d11

[masc]

MLV-App's ffmpeg binary for Windows is already compiled with --enable-nvenc. I own an nVidia card and I could install some distros real quick if further testing is needed.

Oh really? Funny. I loaded the versions for all OS from the same page and the OSX version tells "Codec 'h264_nvenc' is not recognized by FFmpeg."
This is a MLVApp standard call for ffmpeg x264 encoding:

Code: [Select]

"/Users/masc/Documents/MLV_App/platform/build-MLVApp-Desktop_Qt_5_7_0_clangOMP_64bit-Release/MLV App.app/Contents/MacOS/ffmpeg" -loglevel 0 -r 23.98 -y -f rawvideo -s 4464x1900 -pix_fmt rgb48 -i - -i "/Users/masc/Desktop/M22-1233short.wav" -c:a aac -c:v libx264 -preset medium -crf 14 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -vf scale=in_color_matrix=bt601:out_color_matrix=bt709 "/Users/masc/Desktop/M22-1233short.mp4"
Adapt ffmpeg path, wav and output path to your system; and exchange "-i -" to an imput video file "-i input.mov" or something. Could you try encoding with h264_nvenc and tell me what you need to change in order to make it work? I could try to make it work for MLVApp on Windows.  Do you know if there is any ffmpeg call, where ffmpeg tells, if it is able to use this codec? (when using this codec without supported GPU will lead to errors, so this needs to be catched somehow)

[cmh]

I did some tests on a GTX1060, h264_nvenc and h264_cuvid are capped at 4k apparently.

I tried the whole command line but -f rawvideo doesn't work, even with libx264 (or the right size or -profile high444p -pixel_format yuv444p).
M17-2143.mov: corrupt input packet in stream 0
[rawvideo @ 0647e740] Invalid buffer size, packet size 47686523 < expected frame_size 48382272
Error while decoding stream #0:0: Invalid argument

M17-2143.mov, 4392x1836

- h264_cuvid: fails
.\ffmpeg.exe -hwaccel cuvid -c:v h264_cuvid -i 'M17-2143.mov' 'test.mp4'
[h264_cuvid @ 06bd0080] Video width 4392 not within range from 48 to 4096
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (h264_cuvid) -> h264 (libx264))
Error while opening decoder for input stream #0:0 : Invalid argument

- h264_nvenc: fails
.\ffmpeg.exe -i 'M17-2143.mov' -c:v h264_nvenc -preset default 'test.mp4'
[h264_nvenc @ 06f60080] No NVENC capable devices found
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Fails

- hevc_nvenc: pass
.\ffmpeg.exe -i 'M17-2143.mov' -c:v hevc_nvenc -preset default 'test.mp4'

Peppa_Pig-Patata-Parc.mp4, 1025x576

- h264_cuvid: pass
.\ffmpeg.exe -vsync 0 -hwaccel cuvid -c:v h264_cuvid -i 'Peppa_Pig-Patata-Parc.mp4' -c:a copy -c:v h264_nvenc -b:v 5M 'test.mp4'

- h264_nvenc: pass
.\ffmpeg.exe -i '.\Peppa_Pig-Patata-Parc.mp4' -c:v h264_nvenc -preset default 'test.mp4'

- hevc_nvenc: too lazy to test but it should work.

I'll test some more hevc_nvenc tomorrow.

[cmh]

It's on Windows 10 btw and here's some nVidia's doc
https://developer.nvidia.com/video-encode-decode-gpu-support-matrix

[Luther]

As for Luther's suggestion, he's probably thinking of a simple slider for Constant Quality RF. No parsing required.

Yes, like HandBrake does.

[cmh]

Handbrake won't encode huge resolutions with nvenc h.264 either btw.

I can't test the GPU based scalers with h264_nvenc encoding because the ffmpeg binary is not compiled with --enable-libnpp and I can't use -filter_complex nvresize=1:s= wihtout ffmpeg compiled with the flag --enable-nvresize. I can't find a solution for resizing. Other than that there's a problem with the pixel formats for some reason "Option pixel_format not found".

-c:v libx265 replaced by -vcodec hevc_nvenc         
-f rawvideo -s 4392x1826 replaced by -filter_complex nvresize=1:s=4392x1826
-pix_fmt rgb48 replaced by any other supported pixel formats: yuv420p nv12 p010le yuv444p p016le yuv444p16le bgr0 rgb0 cuda d3d11 (I tried yuv420p, yuv444p and rgb0).
-crf replaced by -cq but the quality is different between -crf 18 and -cq 18, need further testing
resizeFilter need futher testing too, I just skipped it.

If someone else wanted to try, take a look at ManWindow.cpp, line 2127.

nvenc is nice to have for fast transcoding but I think it's too limited for this particular usage. For a quick export/preview, I think Huff YUV 10 bits is pretty fast (I haven't tried tbh) otherwise there's cdng.

[cmh]

Apparently nvresize is an unmaintained hack and is not compatible with the current ffmpeg version. There's the scale_npp filter but it's only available with libnpp (NVIDIA Performance Primitives) which require a recompilation to include thi particular nVidia CUDA SDK's proprietary libs (this is why it isn't included in the first place). This would enable resizing and fix the pîxel format errors.
https://github.com/m-ab-s/media-autobuild_suite for recompiling ffmpeg on windows with libnpp
https://docs.nvidia.com/cuda/eula/index.html
I'm not willing to dig futher.

[masc]

Thanks so much @cmh, that's all very interesting. I saved your messages into our github future feature issue #78, to not forget it.
The limited resolution is not nice, but also no problem. So we have to limit the output before giving the stream to ffmpeg, when such codecs are selected. We don't need any resizing support from ffmpeg anymore, because we do it 100% with AVIR now (better quality). Using nVidia SDK might be also a little overkill for such a feature... it is just H.26x, so it will mostly be used as kind of preview.

[Luther]

Handbrake won't encode huge resolutions with nvenc h.264 either btw.

I was talking about CRF values.

-crf replaced by -cq but the quality is different between -crf 18 and -cq 18, need further testing

-qp also works for me. Normally the value ~23 works well for 1080p.

[cmh]

I was talking about CRF values.

Right, we were talking about a gui implementation of that particular feature, I got you. I was just pointing something related to Handbrake, I should have rephrased it.

-qp also works for me. Normally the value ~23 works well for 1080p.

So there's those options to check for quality comparison to match libx264 and libx265 crf values of 18 and 24 (those of MLV-App's by default).
                         :
 -rc                <int>        E..V..... Override the preset rate-control (from -1 to INT_MAX) (default -1)
     constqp                      E..V..... Constant QP mode
     vbr                          E..V..... Variable bitrate mode
     cbr                          E..V..... Constant bitrate mode
     cbr_ld_hq                    E..V..... Constant bitrate low delay high quality mode
     cbr_hq                       E..V..... Constant bitrate high quality mode
     vbr_hq                       E..V..... Variable bitrate high quality mode
 -cq                <float>      E..V..... Set target quality level (0 to 51, 0 means automatic) for constant quality mode in VBR rate control (from 0 to 51) (default 0)
 -qp                <int>        E..V..... Constant quantization parameter rate control method (from -1 to 51) (default -1)

I was reading this https://www.pixeltools.com/rate_control_paper.html

"[...]the quantization parameter QP can only influence the detail of information carried in the transformed residuals. QP has no direct effect on the bitrates associated with overhead, prediction data, or motion vectors. The Mean Average Difference (or MAD) of the prediction error is used for this purpose. [...] Small values of QP more accurately approximate the block's spatial frequency spectrum, but at the cost of more bits. In H.264, each unit increase of QP lengthens the step size by 12% and reduces the bitrate by roughly 12%."

and this https://slhck.info/video/2017/03/01/rate-control.html

"The Quantization Parameter controls the amount of compression for every Macroblock in a frame. Large values mean that there will be higher quantization, more compression, and lower quality. Lower values mean the opposite. [...] Unless you know what you’re doing and you explicitly want this, do not use this mode! Setting a fixed QP means that the resulting bitrate will be varying strongly depending on each scene’s complexity, and it will result in rather inefficient encodes for your input video. You may waste space and you have no control of the actual bitrate."

Correct me if I'm wrong, -cq is a constant quality value while -qp and -rc constqp are constant quantization parameters.
As for a starting point for comparison there's those values.

"[...] In H.264 and H.265, CRF ranges from 0 to 51 (like the QP). 23 is a good default for x264, and 28 is the default for x265. 18 (or 24 for x265) should be visually transparent; anything lower will probably just waste file size. Values of ±6 will result in about half or twice the original bitrate. For VP9, the CRF can be from 0 to 63. Recommended values are from 15–35."

[cmh]

https://slhck.info/video/2017/02/24/crf-guide.html
The CRF versus Constant QP part is pretty interresting too.
The author equates CRF to constant quality.

[cmh]

I did some testing, results are there https://github.com/ilia3101/MLV-App/issues/78#issuecomment-544179865

[masc]

...I also changed the AP0 matrix to the AP1 in processing.c:

Code: [Select]

1.6410233797, -0.3248032942, -0.2364246952
-0.6636628587, 1.6153315917, 0.0167563477
0.0117218943, -0.0082844420, 0.9883948585
This gave me the best color results so far. Please test it too...

I added ACES AP1 as additional processing gamut to our repository. Thank you.

[Luther]

I added ACES AP1 as additional processing gamut to our repository. Thank you.

Nice, thanks @masc!

[DeafEyeJedi]

Nice request @Luther. Thanks @masc for the quick add-on. Sorry for the off-topic but I'm trying to get compiling to work on this mad oldie.

However, keep in mind this is not a priority since this is just a 3rd back up to my so called lab. Running El Captain on this miserable 2007 15" MBP which is still running pretty strong for it's age.

This is probably to be expected but after installing QT 5.6.0 to make my compiling environment work on this which seems to not allow for 10.11 according to the prompt message via Command Line in Terminal. Samples below.



As we know when reading the instructions via Mlv_App_compiler it states that it be can be used for OS X running 10.10 & onward when selecting 'op' via Command Line. What gives?

I've also ran through the script install 'U' three times in the last 24 hours to be sure it wasn't an user error. Even though it still could very well be. 

[masc]

@DeafEyeJedi: I am working on a MBP 13" 2010 with OSX Mavericks (10.9.5). I use Qt 5.6.0 on it and it works like a charme. I installed Qt manually with a download from the Qt page, installed command line tools from OSX and installed a openMP-compiler with brew.
https://download.qt.io/archive/qt/5.6/5.6.0/
Install the compilers first to make sure Qt finds them on first start.
The official download should also run on your MacBook (does it?). Have it running here on Mavericks and El Capitan. I've just no luck on Snow Leopard, on my older MacBook White 2008.

[ozcancelik]

First of all, thank you for your effort.

I have a issue. I have two separate laptops. One is Macbook Pro and one is Hp gaming notebook. On both computers, when you export the same file in the Windows environment with the same settings, the slower macbook pro(bootcamp windows) export faster. On macbook pro  it takes 5 minutes, HP Notebook takes 11 minutes. Also Hp Notebook has faster CPU and also has GPU.

When I check task manager, the only difference between them is CPU usage. The Macbook Pro uses 100% CPU when exporting and Hp uses 40-50% CPU. Why is this problem caused?

Thank you.

[masc]

Without knowing any real facts about your two computers, I suppose some settings to be different, e.g. in receipt. If the CPU is not used at (close to) 100%, you rendered dualISO, or used Highlights/Shadows/Clarity/RBF Denoiser. These algorithms are single threaded. So if the MacBook has 100%, it could have only one or two cores, or the settings used there don't use the points mentioned. The GPU don't cares, because it is not used.

[Quentin]

Slightly off topic ...
I wonder how hard is to include Photo Color Editing within the MLVApp.
The color processing looks superior than native Adobe's.

[Danne]

Ilia3101 is working on a solution:
https://www.magiclantern.fm/forum/index.php?topic=24386.msg221470;topicseen#msg221470