Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - cmh

Pages: 1 ... 4 5 [6]
I also added #include <stdint.h> to src\processing\cafilter\ColorAberrationCorrection.c and src\processing\cafilter\ColorAberrationCorrection.h otherwise it wouldn't compile on Windows.

I tried it very quick with amaze and it's definitly the best solution so far. This is a huge improvement in terms of details over IGV. I should probably test with a color chart, check the skin tones and also the noise level on high iso too because it might dual-purpose as a quick denoiser.

You downloaded the Visual Studio binary of LibRAW? Visual Studio is mostly not compatible with minGW. So you have to compile LibRAW with minGW first.
You are right. Well, since I'm lazy, I'll just try with msys2 and report if it's working.

I got raw2mlv.exe compiled and tried some files (a .dng, a .cr2 and a .nef) but the mlv gererated are 0 kb.

I installed minGW, downloaded LibMLV-master
I downloaded, unzipped LibRaw-0.19.5-Win32 renamed it LibRaw and moved it in raw2mlv
I Installed Visual Studio 2013

In minGW prompt:
Windows@ALPHA ~/sources/LibMLV-master/raw2mlv
$ gcc -c -O3 ../LibMLV/MLVFrameUtils.c
$ gcc -c -O3 ../LibMLV/MLVWriter.c
$ gcc -c -O3 raw2mlv.c
$ gcc *.o libraw.lib -o raw2mlv

Once raw2mlv.exe compiled tried different options:
.\raw2mlv.exe .\RAW_CANON_EOS_1DX.CR2 -o test.mlv
.\raw2mlv.exe .\_DSC0217.dng -o test.mlv
.\raw2mlv.exe .\_DSC1537.NEF -o test.mlv
.\raw2mlv.exe .\RAW_CANON_EOS_1DX.CR2 .\RAW_CANON_EOS_1DX.CR2 .\RAW_CANON_EOS_1DX.CR2 -o test.mlv --bitdepth 12 -f 24000 1001

I also tried compiling raw2mlv with different gcc options
$ gcc *.o libraw.lib -o raw2mlv -lm -lgomp -lstdc++
$ gcc *.o libraw.lib -o raw2mlv -lm -lstdc++

The CRF versus Constant QP part is pretty interresting too.
The author equates CRF to constant quality.

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

"[...]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

"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."

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. for recompiling ffmpeg on windows with libnpp
I'm not willing to dig futher.

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.

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). 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, 4392x1836

- h264_cuvid: fails
.\ffmpeg.exe -hwaccel cuvid -c:v h264_cuvid -i '' '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 '' -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

- hevc_nvenc: pass
.\ffmpeg.exe -i '' -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.

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

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

Everything's working fine on windows 10 except when the Resize box isn't ticked in the Export Settings.
On an anamorphic 5k shot, if this box isn't ticked I got a shorter video which is a 3x3 mosaic of the shot.

Share Your Videos / Family video
« on: September 02, 2019, 11:00:08 PM »
Hello, I'm new to this forum and I just received an EOS M with the 18-55 kit lense.
I just wanted to share one of the video I did two days ago.

Anyway, here's the settings: mv1080p, 12 bit, nothing fancy, recording bits here and there at 24 fps.

This post also gives me the opportunity to thanks the ML devs for providing such amazing open source softwares.

Pages: 1 ... 4 5 [6]