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 - masc

Pages: [1] 2 3 ... 83
I think CUDA is no option at all. In comparison there are just a few computers able to run this, while e.g. OpenCL works on nearly all computers out of the box. So if we would implement GPU features, I'd try again with OpenCL. And there is already a CUDA based MLV tool: fastcinemadng. I was never able to try it - no CUDA GPU in my near.

@iaburn: openmp is not difficult to understand. There are these #pragma lines, which will make 'for' loops multi threaded. There should be no dependency between the loop iterations - this can't work. (e.g. writing on same variable)

This would work:
Code: [Select]
#pragma ...
for(int i = 0; i < n; i++)
    c[i] = a[i] + b[i];

@iaburn: if you know how to use the GPU... I have absolutely no idea here. I just heard it is impossible with C/C++, because it has its own kernel language. So this means mostly rewriting everything.
Yes, in the past we tried to use the GPU for debayering. In the end we had success with it technically, but it was slower as with CPU, because the copy actions between graphic RAM and main RAM needed nearly the same time as if the CPU debayers. So GPU might be cool if you process all on it - single tasks are probably for nothing.

Sometimes it is good, if we just hide features instead of deleting them, if not working... nice find!  8)

are we getting close to a new mlv app official version?
i'd like to try it again comparing to resolve, and any extra speed for the windows version would be most welcomed!
Could anyone share an updated build of Mlv app for Windows?
Each commit and dev work brings us closer... but there is still a way to go. iaburn just started porting dualiso and already did a great job. Thank you!

Don't expect the Windows version to get faster until now - this was a macOS compiler optimization. And Windows offers no hardware support for ProRes encoders.
As compiling MLVApp is really very easy, you could compile each commit you like, test and report.

EDIT: btw I tried MLV App official 1.14 release on my x86 Mac Windows partition and in terms of playback it sits just below latest local build with Qt6+llvm15 on MacOS (but still much higher than official 1.14 build on MacOS).
Official x86 macOS build was compiled with the old llvm@6, for supporting all macOS since 10.9.5. It is possible, that this is slower.

Just sharing MLV App installer (DMG) 'nightly build' (ref. commit 3330563) for OSX x86, built with Qt6 and llvm15:

Auto FocusPixelMap install is broken also with this version. Seems not to work on Qt6.4 yet. Many path related Qt6.4 functions fail (e.g. QFileInfo(<fileName>).exists() ). No idea why. No such problem on Qt5.15.

Qt6.5 is in beta state. You can load it from online installer. They plan to release end of march.

Unfortunately no change. Maybe it is Qt6: AVFoundation sound export had an issue, where Qt6 file, path and call commands did not work at all. With standard C functions: no prob. Map download inherits many many of these Qt lib calls. E.g. a simple QFileInfo("filename").exists() always fails here with Qt6.4, same for QProcess::execute("application").

Hm, here it doesn't work with your version. Loading a clip which needs a map doesn't open the known messagebox. Pixels are visible. On my Intel Mac I've seen, Qt did not find libssl, but it downloaded the maps anyway. In Windows version it was needed for downloading. So in my latest commits I added openssl to the linked LIBs. I don't see libssl and libcrypto in your build yet. Could we try again?

A separate post for a feature request: Would it be hard to add an option to export the MLV files attribute table (as reported in the Session Area when in Table Mode) in a very simple and handy format, say csv maybe?
Done. Please test.

@Danne: nice! FocusPixelMap auto downlod also works now?

So apparently I can confirm very slightly better performance during uncompressed cDNG export with Qt6 / llvm15 local build on Mac x86:
cDNG export is not a major strength of MLVApp - more a side product for a longer feature list. Lossless de-/compression is single threaded. So don't expect much changes here. MLVFS is in advantage here (even if - i think - they use the same algorithm), if the NLE preloads more than one frame - then you get multithreading.

The table was/is already planned and should be doable. I just need the time to do this.

Thanks for that info. I never signed any app I compiled :-D

I get 25fps with both, local latest revision and official build. On BigSur MBA2020 M1.
With fps-override to 60fps, I get 30fps with local latest revision, and 27fps with official build. The 10% more now...

Do you have a special test clip I could test? And which receipt - default?

Interesting I get slow playback with the official MLV.App.v1.14.macOS-ARM64.dmg release. With my own compiled build I get 25fps 100% realtime. Not sure the official build is optimized with llvm@15.
I suspect Ventura OS and the old QT5.15 round trip isnĀ“t working optimal now.

The build I sent you iaburn, is it also choppy/slow?
Are you testing your own compiled build?
The official MLV.App.v1.14.macOS-ARM64.dmg release was compiled with llvm@11. But 25fps is no problem. Latest revision compiled with llvm@15 is maybe up to 10% faster in playback.

Something has to be wrong with my machine. I get now much slower playback speed than before, but no idea what could it be  ???
Do you compile with llvm compiler now? And also: did you uncomment  these lines in .pro file?
Code: [Select]
#Qt5 on Apple Silicon with openMP: install llvm via brew, build Qt5 from source
        QMAKE_CC = /opt/homebrew/opt/llvm/bin/clang
        QMAKE_CXX = /opt/homebrew/opt/llvm/bin/clang++
        QMAKE_LINK = /opt/homebrew/opt/llvm/bin/clang++
        QMAKE_CFLAGS += -fopenmp -ftree-vectorize
        QMAKE_CXXFLAGS += -fopenmp -std=c++15 -ftree-vectorize
        INCLUDEPATH += -I/opt/homebrew/opt/llvm/include
        LIBS += -L/opt/homebrew/opt/llvm/lib -lomp -L/opt/homebrew/opt/openssl/lib -lssl

Hi, just wanted to mention that the dimensions of the video on the screen while playing a video have a massive impact on playback speed.
I didn't noticed because I always have the window maximized and I'm used to have the same performance while playing videos regardless of the window size.
Is it so optimized that it actually process less pixels when the screen is smaller, or is the opposite and final scaling is not optimized?  ::)
This is because of the Qt framework: the used pixels of the video on the screen matter how fast Qt shows the images. We always render the full picture. I wouldn't call it "optimized". So maximized (and maybe with hidden Edit, Session and Audio area (press E, S, A)) it is way slower than in a "small video box".

Do you use the standard Apple compiler? This one offers no openMP (Open Multiprocessing). So many algorithms run single threaded. That is okay for debugging but slower than official version. Install llvm via brew, add the new compiler in "Compilers" in your screenshot frame, and then select in Kits the llvm compiler.
Code: [Select]
brew install llvm

Ps: must admit I got lost in this thread, are performance improvements expected only with Dual ISO? Only on Silicon Macs? Are they due to code optimization? Or just different compilers / newer Qt version? Is llvm the key? I brewed it on my Mac, but how do I make sure that it is actually used by Qt during build process? Many questions, much confusion :o But first things first: let's test this and see if I see some performance improvement at all ;D
The newer compiler and the c++15 flag seems to bring more speed for all operations. I don't know if you used QtCreator: here you select in Kit-Settings what compiler and Qt version to use. On cmd line: when running qmake, you'll have to run it from a Qt binary path. The one you select defines the Qt version to use. But then, I don't know what compiler you selected...

is it possible to implement transfer function like in mlvapp to camera?
I think it would be great to have log recording in camera..
MLVApp uses the power of CPUs - and you know how fast it processes. The camera has a tiny MPU. Transfer function must be applied on all pixels in all frames. I doubt you'll get more than 1fps, probably less... ;)

Could you link to what you are using to install Qt6? A lot of alternatives and I bet all of them takes at least an hour to test..
Exactly this link. Then scroll to "Go opensource", Then "Download the Qt Online Installler". Then you'll need a free Qt account. Then install:
- Qt 6.4.2 macOS, with QtMultimedia
- QtCreator

I think, if you find an Offline Installer from official Qt page, it will do the same. (Years ago I used this - no idea if it changed.)

I used Qt5.15 and Qt6.4 from official Qt-Online-Installer and llvm@15 from brew, on BigSur Intel.
On M1 I am still on Qt5.15 selfcompiled and llvm@15 from brew.

On the Intel machine I see the differences between Qt5 and Qt6: e.g. file access. But maybe it is a problem on this computer, or with Qt6.4, or... :)

I fixed audio export on AVFoundation export with Qt6.4: it seems there are more bugs in Qt lib, because ffmpeg executable could not be found in app image (in Qt5 it works and file definitively was/is existing). I removed Qt calls and replaced with standard C call. Was this working (without my change) with Qt6.5beta?

btw the problem is in the camera or mlvapp actually?
You forgot the user. If you setup low-iso/high-iso wrong, preview also doesn't work. But the problem can be one of the 3, or a mixture of all. DualIso is a difficult topic.

For the sun problem: it is not just a DualIso problem - google for "black sun": you'll find this problem with many RAW cameras, even ARRI and Blackmagic have (or had) this. If you like to implement and if have a nice idea: it would be a great new "RAW Correction".

in their site I saw that you don't need cuda if you use libtorch for c++
They don't say, CUDA is not needed. They say, CUDA is not supported. :) (on mac)
But on the VRT project page you can read the requirments needed: Python 3.8, PyTorch >= 1.9.1, CUDA 11.1  :-\
So I don't expect it to work here on my computers.

Pages: [1] 2 3 ... 83