Messages

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?

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.

regards
bb

@bouncyball: Do you still have a 32bit Windows Qt toolchain?

I don't. Btw, with higher QT versions application is 2x size .

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.

Why pointless

Uh, I meant in the RAW processing part of MLV app (e.g. reading rawdata). But in RGB domain during image processing it makes sense.

@masc

Yes, it's really pointless to do this in the raw part of the mlvapp. Sadly we do not have crop functionality implemented in post processing either. FFMPEG crop option could be implemented during export but this would be just half of the job done.

Yes, needed

Haha! Well, we'll think about it

Well, here is the next part of the story:

The image buffer of silent pics includes OB but Image buffer recorded by other mlv recorders does not, hence, as a1ex mentioned, active area metadata is wrong. When exporting DNGs, this situation handled by rewriting active area metadata by software (mlv_dump, mlvapp). But, the truth is that whole image buffer including OB area goes into DNGs (hence nothing is done to image buffer itself). Instead the DNG header active area appropriate fields filled with correct values. When DNG is opened in some processing software it reads only active area into buffer.

Mlvapp operates with whole image buffer from any mlv and uses it during debayer. So to correct this "misbehaving" it needs to read only active area which is not implemented. Do you really need this feature to be implemented in raw part guys? or maybe crop OB area during postprocessing?

BR
BB

@theBilalFakhouri

I've tested 700D silent mlv shared by you and the story is:

MLVApp exports DNGs without black areas exactly as mlv_dump does, e.g. correctly.
It's just the mlvapp also happens to have image preview/export feature and uses whole buffer for this as it was expected.

Stay tuned... (never loaded silent pic mlv until now)

Care to look into it Bouncyball  ? silent.c a good start I guess?

Haha! I changed my mind . I'll better stick with fixing mlvapp.

@a1ex: Thank you for comprehensive information (as always).

Hi everybody, got a news, I've created the package build for Archlinux for MLV.app, you can find it here https://aur.archlinux.org/packages/mlv.app/

Yay!
Finally MLVApp is in AUR.
Thank you.

Maybe better to change the silent dng/mlv code so it works the same as when recording with mlv_lite?

Exactly!

Different recorder modules use different values. They need to be fixed same way.

Hmm... that HLG stuff is interesting.

Seems all my darkframes generated by MLV_Dump have the wrong framef count in metadata. My new MLVApp generated darkframes don't exhibit the same issue.
So... have I missed something while using MLV_dump?

Correct, mlvdump generated darkframe MLVs have wrong (original) frame count in the header. Unfortunately I did not correct this in mlvdump. Just put correct code into mlvapp.

I already saw it. Patch looks OK! If this eliminates the issue - that's it!

Hello guys!

I see some nasty hickups revealed in the darkframe code. Despite I wrote this part I use this feature very seldom myself so never noticed anything unusual.
Thanks for reporting it and thanks for the patch comited by @masc.

@masc: did that help with debug messages? (indeed handle leak)

regards
bb

deleted

@fsr

Recently we, together with masc, fixed one old bug which caused crashes on MLV importing. It has to be the version you used (AppImage?) does not have that fix. If you can, try to compile latest mlvapp from repository. This should help resolve your issue.

@Eugenia:
Image processing is the beast, it takes most of the time to get usable 16bit RGB data to encoder.
Everything can be improved and this is not an exception and can be optmised. Project is open source so feel free to help us improve the speed .

RAW data must be processed! The comparison to FCP is misleading, because FCP can't process RAW data (reasonably or at

Agree with FCP statement completely.

+1

Official versions do not work with *.dng files.

What do you mean?

@Danne

I think it is better to do it using new libmlv from Ilia. I guess raw2mlv uses it anyway.