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

Pages: [1] 2 3 ... 34
if they stopped the format, what is the best codec to export the mlv files to work with davinci..?
Of course they did not drop the cinemadng support! :)

Also, If you wish, you can export the clip to prores or cineform with "Davinci Wide Gamut/Intermediate" profile and then import in resolve, works nicely. That color space added recently so you have to compile mlvapp from sources.


Can you test those exports with this static build too?

Tested latest commit today on Win10 with Qt 5.13.2, MinGW_64 7.3.0, dynamic build; 1736x976, 14bit, >3200 frames clip, with darkframe subtraction. Exported this clip ~20x to ProRes4444 without any issue over the entire day, using the settings described by theBilalFakhouri.

Very nice job guys! Thank you all!

But... as I said image processing is a real heavy bitch :D

RAW corrections are already multithreaded... I did that as far I remember.
Yeah, yeah, right. we used OpenMP and discussed and corrected some issues then. Not every loop can be OMP accelerated.
In short we OMPed every loop and disabled some after issues. 99% of the correction code (except dual iso) is multithreaded.

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 :P (seems a lot of work).
Yes it surely is a lot of work. Let me explain.

Decoding/Playing engine of MLVApp is not using SDL or any other existing lib. It is written by Markus from scratch in QT with a few humble suggestions from me. This includes everything: video + audio, sync of frames with audio, frame dropping if power is insufficient etc. Just one framebuffer is filling always in the background in a separate thread.

Preparing framebuffer consists of:
* reading the raw frame from MLV according to index (easy task initially written by Ilia and optimized/enhanced by me),
* decode frame it if comressed using lib written by @Baldwin which is quite tricky to optimize further (needs deep understanding of lossless jpeg 92 compression which is used for DNG/cDNG standard),
* do raw correction if checked (darkframe subtract, stripes removal, bad/focus pixels removal, dual iso, smoothing, implemented by me, non multithreaded because it is mostly adaptation of all existing ML/MLVFS raw correction code)

Then multithreaded debayer of framebuffer is done to Camera RGB space and after converting it, for now, to rec709 color space we are ready for image processing which is also uses some multithreading.

The most time consuming parts are (fields for optimization):
* decompresion of the image (some overhead)
* raw correction (mostrly light except smoothing and dual iso, there was also pattern noise removal, disabled now)
* color processing (this is the bitch)

In theory dividing clip logically and processing each chunk in parallel should decrease exporting time but won't improve playing speed.

Writing from scratch is no option as well :P


Single thread performance seems much more important than multi threaded for playback.
Yup this 99% true. As I remember decoding and raw corrections of the frame happens in a separate thread but then debayering and color processing is done as multithreaded.

@masc You have shot some amazing clips before using 5D3/EOS M, it would be cool if you shorten some of them and upload them somewhere (if you still have them and don't mind :) ).
@theBilalFakhouri: did you mean he was more creative while using his good, old 5d2? :D

What was the video card on this system?
Some integrated intel GPU (don't remember Xeon model now) as every server hardware have.

It would be cool to see a set of results across a lot of different systems.
Absolutely agree.

Once in 2018 I benched mlvapp playback (no export) on 160core (4CPU) Xeon system and ... well have a look yourself:

If you make the export settings in mlvapp also in h265_nvenc, will it give a performance boost or is it because fastcinema has a different mlv/cdng export algorithm?
Maybe or maybe not with nvenc supported ffmpeg (encoding only). CDNG export will not be accelerated at all.

could you post samples from the same clip?
+1. Gonna be nice, cut original MLV with mlvapp.

I have some doubts about the the process with the MLV´s in MLV App.
All your issues are not related to MLV App processing at all.

Two previous posters are right.

If you intend to work with DNGs use appropriate software with good debayer, e.g. after effects, resolve, maybe lightroom (very slow workflow), etc...

Do not use 10bit raw! It sucks in comparison to 14 or even 12 bit. 5d3 can easily handle realtime 14bits.

Hm... good question/answer. This means input already was brighter. So I guess the answer is in debayer part or right after debayer.

Btw this audio issue is the main reason why Magic Lantern project even exists...

Trammel was unhappy with audio recording levels on his 5d2 and used his RE and programming skills and chdk project as a basis to write his own ARM code to set the audio levels for his cam. So ML was born :D

Is there an audio adjustment in MLVapp ?

My (audio) recording settings (in Canon menu) are set as low as possible, and my videos are (overload) crackling in the audio.
Using EOSM, and there is no "quieter" microphone setting. Unless it's inside MLVapp or Magic Lantern. The audio is useless.
If audio has clipped during acquisition you can't do anything about it in post, except just lower gain a bit and apply some smoothing filter to not hear that awful crackling. Anyway, information is gone and you're not gonna recover it.

My suggestion is to use external mic/preamp/recorder (built in mic sucks on every eos cam anyway) if eosm can't handle high decibels well (AGC is always on?). And sync it in post.

Hi guys!

I can confirm windows version works and linux version too.
Great job @masc! (as usual)

Here is latest static 64bit windows build if anyone needs it but can't compile. Just unpack and put the binary to mlvapp folder.


crop_rec and derived builds / Re: Danne's crop_rec_4k, 5DIII
« on: January 03, 2022, 09:47:15 AM »
Quality wise vertical resolution is more important than horizontal. So I think this makes no sense.

I assume it must be happening in Qt behind the scenes?
Seems so.

For FHD on M1: Using Rosetta2+Intel-build, I get 20fps. Using arm64 build, I get up to 50fps.
What a huge difference and this is for "lousy" MB Air M1? :P

Edit: I really need my Linux running on M1 ;)
Edit2: or maybe M2 or M3???
Edit3: there are rumors about Apple even dumping ARM in favor of open source RISC5 (none of licensing) in the future...

@masc, Wow! Nice job man!!!

or... if on windows, you closed the terminal window before exporting finished.

Sometimes with ffmpeg h264/h265 codecs you can see top or bottom border line distortions, like blurred line, ribbon of pixels with changing color, etc. I guess it is related to vertical resolution not multiple of 8/16/32 etc. It's due to ffmpeg codecs and not the source image coming from mlvapp.

Win32 version uploaded.

After v1.13 we officially stop releasing win32 build. It can be compiled manually though.


@bouncyball: Do you still have a 32bit Windows Qt toolchain?
I don't. Btw, with higher QT versions application is 2x size :o.

I'll see what can I do.

Installed MLV App today (on windows 10Pro) and was able to export all codec types with no issues..... Something has happened and now I can export to DNG only.

The export process appears to run as normal, but no files are actually exported.
Seems like, annoying ;), console window has been closed, or ffmpeg.exe is not reachable.

Pages: [1] 2 3 ... 34