Messages

Hello guys! My old, good friends and newcomers.

I'm glad this great thread is still active and productive and newcomers providing great contributions!

I have missed you all

regards,
bb

Yeah dual iso is a PITA really.

Mlvfs code was not intended for 10-12bit RAW processing. I changed this and it now supports, "kinda", this RAW modes, but there was a lot of nuances with white and black level calculations/conversions and I have to say that aside of 14bit it is not reliable at all.

Also it is "super quick" as turtle , because of complicated loops which can not be correctly multithreaded with openmp.

Adapting cr2hdr to mlvapp is also hard because @dmilligan did a great job to optimize and sometimes cut corners for speed's sake and those code parts are very different.

I wanna make processing more float.

This sweetest sentence pleasing my eyes

I guess we should release 1.14.1

That's it!

ffmpeg chokes on colortag option if sequence is chosen right?

Debug bails out here:

MainWindow.cpp

Code Select Expand


-> 2619                fwrite(imgBuffer, sizeof( uint16_t ), frameSize, pPipe);


Huston I've got a problem.

Hey guys I cant export fimage sequence (tiff, png, jp2) from mlvapp any more (Linux, v1.14). Craches/closes on fist frame every time with all MLVs.

The issue is not observed with v1.13. Tried 2 ffmpeg binaries with the same result.

Can you guys try this? No special steps needed for reproducing, just load mlv and export to TIFF sequence.

Valgrind does not give any sane information. Guess it is something with pipe but only for image sequences _not_for_video_ files.

Code Select Expand


Process terminating with default action of signal 13 (SIGPIPE)
==7341==    at 0x7113C5F: __libc_write (write.c:26)
==7341==    by 0x7113C5F: write (write.c:24)
==7341==    by 0x70960AC: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1180)
==7341==    by 0x709544F: new_do_write (fileops.c:448)
==7341==    by 0x7097128: _IO_do_write@@GLIBC_2.2.5 (fileops.c:425)
==7341==    by 0x709676D: _IO_new_file_xsputn (fileops.c:1243)
==7341==    by 0x709676D: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1196)
==7341==    by 0x708B886: fwrite (iofwrite.c:39)
==7341==    by 0x15814D: MainWindow::startExportPipe(QString) (MainWindow.cpp:2619)
==7341==    by 0x186400: MainWindow::exportHandler() (MainWindow.cpp:8174)
==7341==    by 0x17C80F: MainWindow::on_actionExport_triggered() (MainWindow.cpp:6628)
==7341==    by 0x30D4DA: MainWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_MainWindow.cpp:1492)
==7341==    by 0x30EBC2: MainWindow::qt_metacall(QMetaObject::Call, int, void**) (moc_MainWindow.cpp:1769)
==7341==    by 0x68CA656: void doActivate<false>(QObject*, int, void**) (in /home/nic/Qt5.14.2/5.14.2/gcc_64/lib/libQt5Core.so.5.14.2)
==7341==
==7341== HEAP SUMMARY:
==7341==     in use at exit: 135,989,283 bytes in 98,200 blocks
==7341==   total heap usage: 1,221,836 allocs, 1,123,636 frees, 8,090,879,848 bytes allocated
==7341==
==7341== Searching for pointers to 98,200 not-freed blocks
==7341== Checked 474,945,176 bytes
==7341==
==7341== LEAK SUMMARY:
==7341==    definitely lost: 896 bytes in 7 blocks
==7341==    indirectly lost: 1,465 bytes in 45 blocks
==7341==      possibly lost: 6,673,015 bytes in 345 blocks
==7341==    still reachable: 129,313,907 bytes in 97,803 blocks
==7341==                       of which reachable via heuristic:
==7341==                         newarray           : 4,288 bytes in 2 blocks
==7341==                         multipleinheritance: 16,240 bytes in 22 blocks
==7341==         suppressed: 0 bytes in 0 blocks
==7341== Rerun with --leak-check=full to see details of leaked memory
==7341==
==7341== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


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.

@theBilalFakhouri

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

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

regards
bb

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

Yeah!
@theBilalFakhouri: did you mean he was more creative while using his good, old 5d2?

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:
Link

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?
Thanks!

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

Is there an audio adjustment in MLVapp ?

Nope.

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.

On Linux it was possible to rename clips so far?

Yup

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.

regards
bb

Quality wise vertical resolution is more important than horizontal. So I think this makes no sense.