A window popped up on the LCD and messages are rolling, something like memory allocating etc.
Etiquette, expectations, entitlement...
@autoexec_bin | #magiclantern | Discord | Reddit | Server issues
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.
Show posts MenuQuote from: Walter Schulz on July 31, 2022, 08:09:04 PM
Please specify build used. "Second latest" is not a proper designation!
Overexposure (=sensor data blown out) and losless compression are rumoured to not get along well. What is your intention to verify that?
Quote from: honza123 on June 08, 2022, 04:58:00 PM
Overlay two footages into one.
- time laps - Full-res Silent picture
- RAW 1920x1290, 25fps,
(5DMkIII, Danne's Build)
https://youtu.be/Nm4epfUE0NU
Quote from: theBilalFakhouri on May 24, 2022, 10:44:43 PM
I don't know how MLVApp code works, never looked into it.
But in theory if we re-write the code somehow so it could utilize more threads for decoding and raw correction then we may have faster playback, would be that possible or *some parts of processing must be single threaded?
*Even if it's must be single threaded, I guess we can process multiple frames at the same time (multi processing), e.g. each frame uses one thread or two frames per thread:
First frame would be processed on CORE 0 while second frame is being processed on CORE 1 and so one for other cores, when CORE 0 finishes, it would load the next frame which we need to process.
I have ~16 FPS playback speed using MLVApp 1.13 (default settings, Bilinear debayer) on Ryzen 3900x, Clip used: UHD 1280x2160 10-bit lossless 23.976 FPS
CPU utilization: is only ~17%
Using Amaze debayer it's ~33% (~11 FPS)
I opened two copies of MLVApp, opened same clip, used default settings (Bilinear debayer), playback for each copy ~16 FPS, CPU utilization is ~35%, multi processing theory works, total ~32 FPS playback speed and there is 65% of CPU power left.
What I am saying in short:
There is a room for enhancement, even if this mean re-writing MLVApp from scratch. I bet someone from MLVApp team would do that (seems a lot of work).
That's why we should start dedicated Patreon account for MLVApp, if one (or two/all) of MLVApp team feels he can improve MLVApp but can't do it for free (fully understandable), funding is a solution for that. I think a lot of users would fund such thing beside there is no legal concerns. if MLVApp team don't want to work on MLVApp for whatever reason (again, it's fully understandable), the idea of creating Patreon account for MLVApp lives, but instead we may hire a freelancer.
I did not mean that, just meant some beautiful MLV clips and used 5D3/EOSM as example (masc seems to have nice MLV clips, and looks good out of the box in MLVApp I guess), I forgot about masc owned 5D2 before , I don't think I have watched 5D2 clips from masc (or I just don't remember how it was). Of course clips from 5D2 would be ideal too, to be used for uncompressed MLV benchmarking
Quote from: Danne on May 24, 2022, 07:13:17 AM
Plenty to read about M1 cpu progression which explains why a "simple" iphone will outperform most(not all) intel processing units. Compiling mlv app with arm 64 makes all the difference in playback. Still mostly rosetta fallback when exporting with ffmpeg but apps are following. Resolve is already working quite nicely too on m1.
Quote from: bouncyball on May 23, 2022, 12:31:57 PM
Absolutely agree.
Once in 2018 I benched mlvapp playback (no export) on 160core (4CPU) Xeon system and ... well have a look yourself:
Link
Quote from: names_are_hard on May 21, 2022, 08:40:09 PM
This is not true. The article you linked to was about a specific *Intel* library that *Intel* deliberately made to be poorly optimised for AMD CPUs. It has no relevance to "low level compilers". Only one specific Intel library. MLV App isn't even using that library! Compilers optimise just fine on AMD.
Benchmarking is always quite tricky. Since we can run MLVApp anywhere, when you're interested in MLVApp performance, it's the obvious best choice to use. Ideally, script running MLVApp, always with the same input file, processing options etc. That way you can get reproducible results, and you can share the script with other people so they can test on their systems. It would be cool to see a set of results across a lot of different systems.
Quote from: names_are_hard on May 21, 2022, 05:16:01 PM
MacOS has never had a Linux kernel.
Please don't give completely unfounded advice. This is just untrue. It's probably the *opposite* of true for MLVApp, which is heavily threaded; current Zen based AMD CPUs normally beat Intel (and Apple M1) based systems in multi-threaded workloads.
Don't guess. Don't assume benchmarks *on a different piece of software* will be representative. Benchmarking is notoriously complicated. Benchmark using MLVApp on different systems; it's free and available on all OSes! If somebody gives me an MLV file and instructions, I'll bench on my modern 8c/16t AMD Linux system.
Quote from: masc on May 21, 2022, 12:52:29 PM
Rendering on macOS has always been faster than on Windows. When I compare some of my systems: a dualcore i5 2.4GHz with macOS has a similar performance like a quadcore i7 3.4GHz with Win10.
There is no optimization for certain systems in MLVApp. The code is identical (appart from AVFoundation export which is Apple only and post export scripts) for all OS. The only difference are the compilers and the operating system.
On Linux I saw very similar performance to macOS, but I don't use this really.
Quote from: masc on May 20, 2022, 10:58:23 PM
I recommend to sharpen 1x3 footage (if neccessary at all) in NLE after MLVApp export. For an improvement inside MLVApp we don't need a 1x3 optimization option - we would need a complete rewrite with a different conecpt.
Quote from: masc on May 20, 2022, 09:29:59 PM
What do you mean with "optimized"?! What should be different for 1x3? MLVApp is optimzied for all options we have - as good as we can
Page created in 0.097 seconds with 13 queries.