Etiquette, expectations, entitlement...
@autoexec_bin | #magiclantern | Discord | Reddit | Server issues
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.
, because of complicated loops which can not be correctly multithreaded with openmp.I wanna make processing more float.This sweetest sentence pleasing my eyes
-> 2619 fwrite(imgBuffer, sizeof( uint16_t ), frameSize, pPipe);
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!
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.
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.
What I am saying in short:Yes it surely is a lot of work. Let me explain.
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).
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 mindYeah!
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.
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.
Thanks!
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.
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.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.
Using EOSM, and there is no "quieter" microphone setting. Unless it's inside MLVapp or Magic Lantern. The audio is useless.
On Linux it was possible to rename clips so far?Yup