Author Topic: MLV App 1.11 - All in one MLV Video Post Processing App [Windows, Mac and Linux]  (Read 388777 times)

743v04

  • New to the forum
  • *
  • Posts: 8
Hello Masc and Danne, thank you both for getting back to me so fast, as well as for creating these amazing tools for all of us to use. I just tested this same MLV from my MBP running High Sierra and am getting what seems like a similar crash. Here is the crash report from it: https://pastebin.com/8STnArw5

Edit: Here are screen captures of my export settings that both crash similarly: https://imgur.com/a/HMpVIEH

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 1548
Hello Masc and Danne, thank you both for getting back to me so fast, as well as for creating these amazing tools for all of us to use. I just tested this same MLV from my MBP running High Sierra and am getting what seems like a similar crash. Here is the crash report from it: https://pastebin.com/8STnArw5

Edit: Here are screen captures of my export settings that both crash similarly: https://imgur.com/a/HMpVIEH
The report tells exactly the same.
5D2.212 | EOSM.202

QuickHitRecord

  • Member
  • ***
  • Posts: 152
Quote
This is to be expected: Log saves your shadows and highlights at the cost of midtones (which get compressed by the log function). So it is better to grad 100% in MLVApp or 100% in another app. In MLVApp you could also apply .cube LUTs. This should look better and should not bring those artifacts, because processing is 16bit instead of 10bit if you apply it in Premiere on a ProRes file.

Thank you. I am getting much cleaner results applying the LUT in MLV App.
5DmIII | January 27 2017 Nightly Build (Firmware: 1.23) | KomputerBay 256GB CF Cards (1066x & 1200x)

743v04

  • New to the forum
  • *
  • Posts: 8
The report tells exactly the same.
Yes, I just thought it was worth mentioning since you said there were no issues with 10.13, this MBP is running 10.13.6 that produced the second crash log. As opposed to the original one where it was taken from a 10.14 device. I guess I will try to see if there is any updates available for my 10.13.6 device though and go from there.

Danne

  • Contributor
  • Hero Member
  • *****
  • Posts: 6438
Can you share your exact export recipe? Or a screen recording of what you are doing in mlv app.

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 1548
Can you share your exact export recipe? Or a screen recording of what you are doing in mlv app.
743v04 wrote it also happens with default receipt. (I hope with MLVApps default receipt and not with a user defined one.)

Yes, I just thought it was worth mentioning since you said there were no issues with 10.13, this MBP is running 10.13.6 that produced the second crash log. As opposed to the original one where it was taken from a 10.14 device. I guess I will try to see if there is any updates available for my 10.13.6 device though and go from there.
Hmmm...
5D2.212 | EOSM.202

Danne

  • Contributor
  • Hero Member
  • *****
  • Posts: 6438
743v04 wrote it also happens with default receipt.
I trust only screen recordings. But, could be a number of things.

743v04

  • New to the forum
  • *
  • Posts: 8
I trust only screen recordings. But, could be a number of things.
I have a screen recording of it, I will upload that in a few hours.

Edit: https://we.tl/t-NOWe73RkyK

https://imgur.com/a/qtVTV7K

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 1548
I tried again and again and again. I now also tried to choose "Force AMaZE" and tried to "unselect" the clip in the session list before export, exactly as you did. Now I got exactly your crash, maybe one of 10..20 trys. With debugger enabled I had "no luck crashing the app" yet.

Edit: after another 20 times it happend also once with selected and "Receipt configuration" debayer in export settings. But it seems to come each time from Apple ProRes Encoder... whyever.

Edit2: @Ilia: The crash happens when the function freeAVEncoder calls a free (there are just 2). While this is called, the Apple ProRes Encoder seems still to work (I see 2 worker threads from Apple Encoder and one crashed the app). Is there a way to ask the Encoder for beeing ready?
5D2.212 | EOSM.202

ilia3101

  • Moderators
  • Hero Member
  • *****
  • Posts: 897
It only crashes with force amaze? But on freeAVEncoder call?

They aren't related though??

743v04

  • New to the forum
  • *
  • Posts: 8
No matter which debayer method I use, either with the force options in the export settings or using the receipt configuration, I always get this same crash. If there is a debugging tool that I could run on my end to find anything else out let me know. Thanks for taking the time to look into this.

Danne

  • Contributor
  • Hero Member
  • *****
  • Posts: 6438
Did you test compiling yourself with mac compiler in first post? Run the OP menu option after dependencies are installed.

tupp

  • Freshman
  • **
  • Posts: 79
Thank you for the wonderful MLV App!

I run Devuan Linux, and I just installed the the 1.11 appimage!

I also installed the focus pixel maps (fantastic feature!), but the MLV App Wiki is problematic in regards to its instructions on installing the focus pixel maps on a Linux system.

One issue is that there are two mlvapp binaries in the appimage, but only one of them works (unfortunately, not the one referred to in the "Fix Focus Dots" instructions).  The two binaries are the same size, but I ran a checksum on both binaries, and got different results.

Another complication is that the appimage already includes a version of ffmpeg that works, so there might not be any need to copy the user's version of ffmpeg into the extracted appimage folders, as the wiki instructs.

Also, the focus pixel maps can merely be "copied" to a sub-directory of the extracted appimage.  It would likely be better to instruct Linux users to just copy the files (or at least mention that possibility), rather than only telling Linux users to "install" the focus pixle maps in the nice drag-&-drop manner suggested by the Wiki.  Some Linux users use simple window managers, rather than full-blown desktops, so the simple file manger that they use might not be capable of dragging/dropping files into other apps.

There is probably a way to make these instructions clearer, and I would be happy to contribute in that regard.

While I was exploring the extracted files, I noticed that there is a "plugin" folder.  It would be amazing if a version of the Cinelerra "Blue Banana" plug-in could be imported into MLV App.

One more thing, is there a way to import non-mlv and non-raw files?  I could probably convert a video to cinema DNGs or to jpegs, but it would be incredible if MLV App could manipulate mp4's, Quicktime files, mkv's, etc.  If it could do so, I would use it for everything!

Thanks!

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 1548
It only crashes with force amaze? But on freeAVEncoder call?

They aren't related though??
No, it happens with all debayer algorithms. It just popped up first time for me when I used this option. But it is not related.

No matter which debayer method I use, either with the force options in the export settings or using the receipt configuration, I always get this same crash. If there is a debugging tool that I could run on my end to find anything else out let me know. Thanks for taking the time to look into this.
Sounds your computer is ideal for debugging this. If you like install the toolchain, compile the app as debug version and start it with debugger. The debugger tells you the line of code of the crash. This would be intersting. I got no crash at all with debugger...
5D2.212 | EOSM.202

743v04

  • New to the forum
  • *
  • Posts: 8
Sounds your computer is ideal for debugging this. If you like install the toolchain, compile the app as debug version and start it with debugger. The debugger tells you the line of code of the crash. This would be intersting. I got no crash at all with debugger...

I will give that a go over the weekend and report back. I am also trying Danne's recommendation in the meantime.

Edit: Self compiling did fix this for me, not sure if compiling the app as debug version is useful still, if so I'd be happy to do that. Sorry for the hassle and thanks for the help!

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 1548
One issue is that there are two mlvapp binaries in the appimage, but only one of them works (unfortunately, not the one referred to in the "Fix Focus Dots" instructions).  The two binaries are the same size, but I ran a checksum on both binaries, and got different results.
Okaaay. Two binaries? I never tried to unpack the image. I just have compiled it and I was happy when the appimage process ended without error but with an appimage. :)

Another complication is that the appimage already includes a version of ffmpeg that works, so there might not be any need to copy the user's version of ffmpeg into the extracted appimage folders, as the wiki instructs.
The included ffmpeg version should be used always!!! If you use another ffmpeg, nobody knows if it works for all features. It is just important, that ffmpeg is in the same folder as the mlvapp executable. Otherwise it should not work. Same for raw2mlv. It must be located in the same folder!

Also, the focus pixel maps can merely be "copied" to a sub-directory of the extracted appimage.  It would likely be better to instruct Linux users to just copy the files (or at least mention that possibility), rather than only telling Linux users to "install" the focus pixle maps in the nice drag-&-drop manner suggested by the Wiki.  Some Linux users use simple window managers, rather than full-blown desktops, so the simple file manger that they use might not be capable of dragging/dropping files into other apps.
The reason why we write to use the drag and drop feature is, it always works. In the past it felt like 90% of the users failed with manual copy actions. And for some people even the drag and drop is hard to understand. But if copying the files works for, you can always do that!

There is probably a way to make these instructions clearer, and I would be happy to contribute in that regard.
Feel free to contribute! That is very much welcome! Also if you find a way to create the appimage in a better way, you can help if you like. We implemented MLVApp mostly on OSX. On Windows I know how to get it to work. But on Linux I am just happy if it compiles and creates the appimage somehow, and it starts if I doubleclick the image. ;)

While I was exploring the extracted files, I noticed that there is a "plugin" folder.  It would be amazing if a version of the Cinelerra "Blue Banana" plug-in could be imported into MLV App.
No idea what this plugin folder is and what it does. Should be something from the appimage. MLVApp has no plugin feature at the moment.

One more thing, is there a way to import non-mlv and non-raw files?  I could probably convert a video to cinema DNGs or to jpegs, but it would be incredible if MLV App could manipulate mp4's, Quicktime files, mkv's, etc.  If it could do so, I would use it for everything!
There is a way to import non-mlv, yes, but there is no way to import non-raw files. DNG, CR2, ... can be transcoded to MLV via raw2mlv, which is included in the package. Use "Transcode and Import" from the menu. You'll find the menu action only, if raw2mlv is on the right place (same folder as MLVApp executable). MLVApp imports the created MLV when transcoding is ready.
5D2.212 | EOSM.202

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 1548
Self compiling did fix this for me
Really? That is funny... :D Thanks for the feedback!

not sure if compiling the app as debug version is useful still, if so I'd be happy to do that.
It would be useful, if you get it crashed with running debugger. This way we could maybe fix the bug. But for this we must have found it. But now you maybe see my problem: without this information I can't really help to find the bug...

Edit: does you version use all cores for the standard receipt? If not, it maybe compiled without openMP feature (this enables multithreading).
5D2.212 | EOSM.202

Danne

  • Contributor
  • Hero Member
  • *****
  • Posts: 6438
I will give that a go over the weekend and report back. I am also trying Danne's recommendation in the meantime.

Edit: Self compiling did fix this for me, not sure if compiling the app as debug version is useful still, if so I'd be happy to do that. Sorry for the hassle and thanks for the help!
You compiled with OP option? If so openmp is included.

Edit: also retry the official build. Maybe the compiler script iinstalls your faulty dependency.

743v04

  • New to the forum
  • *
  • Posts: 8
You compiled with OP option? If so openmp is included.

Edit: also retry the official build. Maybe the compiler script iinstalls your faulty dependency.

Yes I used the OP option and that fixed it. Also replaced it with the official build again and that kept it working too. This is all on my MBP with 10.13.6, haven't tested 10.14 yet but I feel like that device I am on my own with the hardware being used. Thanks again everyone, I will keep this in mind if I run into a similar problem in the future  :D

tupp

  • Freshman
  • **
  • Posts: 79
Okaaay. Two binaries? I never tried to unpack the image. I just have compiled it and I was happy when the appimage process ended without error but with an appimage. :)
Here is the directory/file tree of the unpacked AppImage:
Code: [Select]
squashfs-root
├── AppRun -> usr/bin/mlvapp
├── Makefile
├── mlvapp
├── mlvapp.desktop
├── MLVAPP.png
├── raw2mlv
└── usr
    ├── bin
    │   ├── ffmpeg
    │   ├── mlvapp
    │   ├── qt.conf
    │   └── raw2mlv
    ├── lib
    │   ├── libasyncns.so.0
    │   ├── libdbus-1.so.3
    │   ├── libEGL.so.1
    │   ├── libffi.so.6
    │   ├── libFLAC.so.8
    │   ├── libgbm.so.1
    │   ├── libgmodule-2.0.so.0
    │   ├── libgomp.so.1
    │   ├── libgstapp-1.0.so.0
    │   ├── libgstaudio-1.0.so.0
    │   ├── libgstbase-1.0.so.0
    │   ├── libgstpbutils-1.0.so.0
    │   ├── libgstreamer-1.0.so.0
    │   ├── libgsttag-1.0.so.0
    │   ├── libgstvideo-1.0.so.0
    │   ├── libgthread-2.0.so.0
    │   ├── libicudata.so.56
    │   ├── libicui18n.so.56
    │   ├── libicuuc.so.56
    │   ├── libjasper.so.1
    │   ├── libjpeg.so.8
    │   ├── libjson-c.so.2
    │   ├── libogg.so.0
    │   ├── liborc-0.4.so.0
    │   ├── libpcre.so.3
    │   ├── libpng12.so.0
    │   ├── libpulsecommon-4.0.so
    │   ├── libpulse-mainloop-glib.so.0
    │   ├── libpulse.so.0
    │   ├── libqgsttools_p.so.1
    │   ├── libQt5Core.so.5
    │   ├── libQt5DBus.so.5
    │   ├── libQt5Gui.so.5
    │   ├── libQt5Multimedia.so.5
    │   ├── libQt5MultimediaWidgets.so.5
    │   ├── libQt5Network.so.5
    │   ├── libQt5OpenGL.so.5
    │   ├── libQt5Widgets.so.5
    │   ├── libQt5XcbQpa.so.5
    │   ├── libsndfile.so.1
    │   ├── libvorbisenc.so.2
    │   ├── libvorbis.so.0
    │   ├── libwayland-client.so.0
    │   ├── libwayland-server.so.0
    │   ├── libwrap.so.0
    │   ├── libX11-xcb.so.1
    │   ├── libXau.so.6
    │   ├── libxcb-dri2.so.0
    │   ├── libxcb-dri3.so.0
    │   ├── libxcb-glx.so.0
    │   ├── libxcb-present.so.0
    │   ├── libxcb-sync.so.1
    │   ├── libxcb-xfixes.so.0
    │   ├── libXdamage.so.1
    │   ├── libXdmcp.so.6
    │   ├── libXext.so.6
    │   ├── libXfixes.so.3
    │   ├── libXi.so.6
    │   ├── libxshmfence.so.1
    │   └── libXxf86vm.so.1
    ├── plugins
    │   ├── audio
    │   │   ├── libqtaudio_alsa.so
    │   │   └── libqtmedia_pulse.so
    │   ├── bearer
    │   │   ├── libqconnmanbearer.so
    │   │   ├── libqgenericbearer.so
    │   │   └── libqnmbearer.so
    │   ├── imageformats
    │   │   ├── libqgif.so
    │   │   ├── libqicns.so
    │   │   ├── libqico.so
    │   │   ├── libqjp2.so
    │   │   ├── libqjpeg.so
    │   │   ├── libqtga.so
    │   │   ├── libqtiff.so
    │   │   ├── libqwbmp.so
    │   │   └── libqwebp.so
    │   ├── mediaservice
    │   │   ├── libgstaudiodecoder.so
    │   │   ├── libgstcamerabin.so
    │   │   ├── libgstmediacapture.so
    │   │   └── libgstmediaplayer.so
    │   ├── platforminputcontexts
    │   │   ├── libcomposeplatforminputcontextplugin.so
    │   │   └── libibusplatforminputcontextplugin.so
    │   ├── platforms
    │   │   └── libqxcb.so
    │   └── xcbglintegrations
    │       ├── libqxcb-egl-integration.so
    │       └── libqxcb-glx-integration.so
    ├── share
    │   ├── applications
    │   │   └── mlvapp.desktop
    │   ├── doc
    │   │   ├── libasyncns0
    │   │   │   └── copyright
    │   │   ├── libdbus-1-3
    │   │   │   └── copyright
    │   │   ├── libegl1-mesa-lts-xenial
    │   │   │   └── copyright
    │   │   ├── libffi6
    │   │   │   └── copyright
    │   │   ├── libflac8
    │   │   │   └── copyright
    │   │   ├── libglib2.0-0
    │   │   │   └── copyright
    │   │   ├── libgstreamer1.0-0
    │   │   │   └── copyright
    │   │   ├── libgstreamer-plugins-base1.0-0
    │   │   │   └── copyright
    │   │   ├── libjasper1
    │   │   │   └── copyright
    │   │   ├── libjpeg-turbo8
    │   │   │   └── copyright
    │   │   ├── libjson-c2
    │   │   │   └── copyright
    │   │   ├── libogg0
    │   │   │   └── copyright
    │   │   ├── liborc-0.4-0
    │   │   │   └── copyright
    │   │   ├── libpcre3
    │   │   │   └── copyright
    │   │   ├── libpng12-0
    │   │   │   └── copyright
    │   │   ├── libpulse0
    │   │   │   └── copyright
    │   │   ├── libpulse-mainloop-glib0
    │   │   │   └── copyright
    │   │   ├── libsndfile1
    │   │   │   └── copyright
    │   │   ├── libvorbis0a
    │   │   │   └── copyright
    │   │   ├── libvorbisenc2
    │   │   │   └── copyright
    │   │   ├── libwayland-client0
    │   │   │   └── copyright
    │   │   ├── libwayland-server0
    │   │   │   └── copyright
    │   │   ├── libwrap0
    │   │   │   └── copyright
    │   │   ├── libx11-xcb1
    │   │   │   └── copyright
    │   │   ├── libxau6
    │   │   │   └── copyright
    │   │   ├── libxcb-dri2-0-dev
    │   │   │   └── copyright
    │   │   ├── libxcb-dri3-0
    │   │   │   └── copyright
    │   │   ├── libxcb-glx0-dev
    │   │   │   └── copyright
    │   │   ├── libxcb-present0
    │   │   │   └── copyright
    │   │   ├── libxcb-sync1
    │   │   │   └── copyright
    │   │   ├── libxcb-xfixes0
    │   │   │   └── copyright
    │   │   ├── libxdamage1
    │   │   │   └── copyright
    │   │   ├── libxdmcp6
    │   │   │   └── copyright
    │   │   ├── libxext6
    │   │   │   └── copyright
    │   │   ├── libxfixes3
    │   │   │   └── copyright
    │   │   ├── libxi6
    │   │   │   └── copyright
    │   │   ├── libxshmfence1
    │   │   │   └── copyright
    │   │   └── libxxf86vm1
    │   │       └── copyright
    │   └── icons
    │       └── hicolor
    │           └── 512x512
    │               └── apps
    │                   └── MLVAPP.png
    └── translations
        ├── qt_bg.qm
        ├── qt_ca.qm
        ├── qt_cs.qm
        ├── qt_da.qm
        ├── qt_de.qm
        ├── qt_en.qm
        ├── qt_es.qm
        ├── qt_fi.qm
        ├── qt_fr.qm
        ├── qt_gd.qm
        ├── qt_he.qm
        ├── qt_hu.qm
        ├── qt_it.qm
        ├── qt_ja.qm
        ├── qt_ko.qm
        ├── qt_lv.qm
        ├── qt_pl.qm
        ├── qt_ru.qm
        ├── qt_sk.qm
        └── qt_uk.qm

57 directories, 153 files

As you can see, there are two "mlvapp" binaries, along with the "AppRun" link to the working mlvapp binary).

Also note the two "raw2mlv" binaries plus the single instance of "ffmpeg."

In addition, there are two "MLVAPP.png" images.


The included ffmpeg version should be used always!!! If you use another ffmpeg, nobody knows if it works for all features. It is just important, that ffmpeg is in the same folder as the mlvapp executable. Otherwise it should not work. Same for raw2mlv. It must be located in the same folder!
The MLV-App Wiki instructs Linux users to copy their system's version of ffmpeg into MLV-Apps extracted root directory.  This action is sort of futile, as the mlvapp binary in that root directory fails while seeking dependencies on the user's system (specifically, in "/usr/lib/").

However, if one runs the mlvapp binary found in the extracted "/squashfs-root/usr/bin/" directory, MLV-App and the included ffmpeg binary works.  By the way, I tried replacing that included version of ffmpeg with the one on my system and I didn't have any trouble exporting an MP4 file from MLV-App.


The reason why we write to use the drag and drop feature is, it always works. In the past it felt like 90% of the users failed with manual copy actions. And for some people even the drag and drop is hard to understand. But if copying the files works for, you can always do that!
After more than 40 years of the personal computing era, the preponderance of computer illiteracy is staggering.  It is amazing how many folks have trouble with something as fundamental as copying files from one directory to another.

Regardless, the instructions should mention the fact that the focus pixel maps are merely copied into a directory, and the instructions should also give the location and name of that directory ("/squashfs-root/usr/bin/" for the extracted Linux AppImage).


Feel free to contribute! That is very much welcome! Also if you find a way to create the appimage in a better way, you can help if you like. We implemented MLVApp mostly on OSX. On Windows I know how to get it to work. But on Linux I am just happy if it compiles and creates the appimage somehow, and it starts if I doubleclick the image. ;)
Okay!   Should I just DM the instructions to you?

In regards to creating an AppImage, my experience is limited mostly to running them and to the extraction that I had to perform to add the focus pixel maps.  I cannot speak for every Linux user, but I would prefer the additional option of having the files and directories of the app packed into a standard tar archive (or a compressed tar archive).  Although one can run an AppImage with only one command (or mouse click), the user must still unpack the MLV-App Appimage to use focus pixel maps.   It takes the same effort to unpack a tar archive and then run (click on) the binary.  Plus, there is no "compiling" a tar archive -- just create the archive (just like a zip file) and compress it, if you like.

I am happy to help in the creation of an MLV-App tar archive (and in cleaning-up the files/folders), but making a tar archive from folders and files is really "dumb-simple."


No idea what this plugin folder is and what it does. Should be something from the appimage. MLVApp has no plugin feature at the moment.
Judging from what's listed in the directory/file tree above, it appears that the "/squashfs-root/usr/plugins/" directory contains needed shared object libraries related to decoding/encoding audio and video formats.

If a version of the "Blue Banana" interface was an option in MLV-App, it could ease simple color grading (although it is very powerful in Cinelerra).


There is a way to import non-mlv, yes, but there is no way to import non-raw files. DNG, CR2, ... can be transcoded to MLV via raw2mlv, which is included in the package. Use "Transcode and Import" from the menu. You'll find the menu action only, if raw2mlv is on the right place (same folder as MLVApp executable). MLVApp imports the created MLV when transcoding is ready.
I thought I saw a way to import jpegs in the MLV-App menus. Even if one converted a video to a series of jpegs and there was an import function, image degradation would be a concern.  If importing jpegs is not possible, it might be a little unwieldy to convert video files to a compatible raw format, and then transcode with raw2mlv.

Some of us shoot ML H264 with boosted bit rate and/or all-I settings.  So, it would be great to be able to use MLV-App on those ML-generated files.

Thanks!

masc

  • Contributor
  • Hero Member
  • *****
  • Posts: 1548
As you can see, there are two "mlvapp" binaries, along with the "AppRun" link to the working mlvapp binary).
Also note the two "raw2mlv" binaries plus the single instance of "ffmpeg."
In addition, there are two "MLVAPP.png" images.
Okay. I bet this should only be inside the structure, but not in the root folder. I hope the mlvapp executable inside bin is newer.

The MLV-App Wiki instructs Linux users to copy their system's version of ffmpeg into MLV-Apps extracted root directory.  This action is sort of futile, as the mlvapp binary in that root directory fails while seeking dependencies on the user's system (specifically, in "/usr/lib/").
Where have you read this? I just see "copy "ffmpeg" and "raw2mlv" executable in this newly created directory". Nobody wrote (as I know) of a systems version of ffmpeg. Those hints came from another user who wanted to help us - maybe these days the archive was wrong the same way. I understood to copy ffmpeg from bin to archive root. But I would never ever use "any" ffmpeg.

However, if one runs the mlvapp binary found in the extracted "/squashfs-root/usr/bin/" directory, MLV-App and the included ffmpeg binary works.  By the way, I tried replacing that included version of ffmpeg with the one on my system and I didn't have any trouble exporting an MP4 file from MLV-App.
Okay, but this is just one function you used from ffmpeg. There are many others like stabilizer and ...

After more than 40 years of the personal computing era, the preponderance of computer illiteracy is staggering.  It is amazing how many folks have trouble with something as fundamental as copying files from one directory to another.
This might be the probem: today the guys grow with iPhone using "2-button-apps".

Should I just DM the instructions to you?
You could also create an issue on github. Maybe others like to contribute as well with that. And with Linux I believe everything anybody tells me  ;D

I thought I saw a way to import jpegs in the MLV-App menus. Even if one converted a video to a series of jpegs and there was an import function, image degradation would be a concern.  If importing jpegs is not possible, it might be a little unwieldy to convert video files to a compatible raw format, and then transcode with raw2mlv.

Some of us shoot ML H264 with boosted bit rate and/or all-I settings.  So, it would be great to be able to use MLV-App on those ML-generated files.
The main problem is, we need RAW data. For non-RAW pictures/videos you must somehow "undo calculate" unknown camera matrix, burned-in white balance and other things. I think this would never look good.
5D2.212 | EOSM.202

ilia3101

  • Moderators
  • Hero Member
  • *****
  • Posts: 897
The main problem is, we need RAW data. For non-RAW pictures/videos you must somehow "undo calculate" unknown camera matrix, burned-in white balance and other things. I think this would never look good.

Could just interpret it as sRGB, and figure out a basic curve to un-do it. But dynamic range would be bad.

This could be done very well with log I think. Log could be input in to a raw converter quite easily. Unfortunately this won't be happening with MLV App, it's tightly wrapped to MLV.

I haven't been using ML or MLV App lately, but in the wake of our recent quarantine, I decided to try them out once again. MLV App is a wonderful piece of software. I have one question though. When I set the profile preset to "Alexa Log-C" and then export to ProRes for grading later, I get some crazy banding in the resulting clips when a simple Log-C to Rec709 LUT is applied. Here is an example:



I seem to remember having problems with this in the past as well. Is there a way to export without this issue? In my case, I am using MLV App v1.11 and applying highlight reconstruction, making color temperature tweaks, and then exporting to 4K ProRes HQ. Then I'm bringing it into Premiere and applying the standard ALEXA_Default_LogC2Rec709 LUT in Lumetri. The camera is a 5D3 with 1.23 and a build from 2017.

Have you tried other export formats? Other versions of pro res? Which prores did you use?

Also... MLV App might do a better conversion to rec709 than a LUT someone else designed. Set tonemapping to reinhard 3/5 and gamma to 2.5, then tweak the dark/light sliders to your taste...



After all, any log to rec709 lut will have smooth highlight roll-off and a subjective curve already built in.

tupp

  • Freshman
  • **
  • Posts: 79
Okay. I bet this should only be inside the structure, but not in the root folder. I hope the mlvapp executable inside bin is newer.
The working mlvapp binary is located in the /squashfs-root/usr/bin/ directory.  The AppImage has a working symlink (AppRun -> usr/bin/mlvapp) that is integral to the AppImage structure.

Do you guys send the app (and its directories) around in "zip" files before creating the AppImage?  If so, zipping without an "allow symlinks" flag would probably explain the broken binary in the root directory.


Where have you read this? I just see "copy "ffmpeg" and "raw2mlv" executable in this newly created directory". Nobody wrote (as I know) of a systems version of ffmpeg. Those hints came from another user who wanted to help us - maybe these days the archive was wrong the same way. I understood to copy ffmpeg from bin to archive root. But I would never ever use "any" ffmpeg.
I was mistaken.  The Wiki doesn't specify where to get ffmpeg, so I just assumed that it meant one must provide it.  However, others might interpret those instructions similarly.

It shouldn't be too much trouble to make things clearer in the instructions.


Okay, but this is just one function you used from ffmpeg. There are many others like stabilizer and ...
I know.  I just tried my system's ffmpeg to see what would happen.


You could also create an issue on github. Maybe others like to contribute as well with that. And with Linux I believe everything anybody tells me  ;D
Ha, ha!

It would be great if I could send the instructions through this site.  I have no experience with github, but it's owned by Microsoft.  I would like to avoid signing-up with and giving details to Microsoft.


The main problem is, we need RAW data. For non-RAW pictures/videos you must somehow "undo calculate" unknown camera matrix, burned-in white balance and other things. I think this would never look good.
Could just interpret it as sRGB, and figure out a basic curve to un-do it. But dynamic range would be bad.  This could be done very well with log I think. Log could be input in to a raw converter quite easily. Unfortunately this won't be happening with MLV App, it's tightly wrapped to MLV.
Okay.  Just asking.  It's a shame that it can't be, though.

I have already made a compressed Linux tarball of MLV-App.  I cleaned out a lot of the compiling cruft, and I created a README file.  I also made a zip version (with the symlinks flag).  These archives are 60MB (smaller than the AppImage).

I don't see any way of attaching files to posts nor to direct messages here, so if anyone would like to have these files, we have to figure out how to make that happen.

Thanks!

Erkett

  • New to the forum
  • *
  • Posts: 9
I'm feeling good with the 1.11 release with manual Bad Pixel Picker!
BEST THING EVER! :D

Danne

  • Contributor
  • Hero Member
  • *****
  • Posts: 6438
I'm feeling good with the 1.11 release with manual Bad Pixel Picker!
BEST THING EVER! :D
It is awesome. Thanks to masc and bouncyball.