MLV App 1.14 - All in one MLV Video Post Processing App [Windows, Mac and Linux]

Started by ilia3101, July 08, 2017, 10:19:19 PM

Previous topic - Next topic

0 Members and 5 Guests are viewing this topic.

JADURCA

a1ex and Danne, looks amazing! Thanks for your time and effort! I'm doing it right away! Not an experiment person with script, I would learn.

togg

Used MLV App in a 3 day project this week. (screenshots taken from MLV App : https://imgur.com/a/joPJGqc )
I can't say it was easy but I'm impressed for all the progress! For me though, even if I like new features and such, there're things that should come first. I came up with a little list, in order of importance more or less.

1) Automatically skip frames / fix could not save error.
I'm not sure what is going on here, I've tried with different hard drives, my computer *should* not be the problem, but this problem came up with over night conversion: https://i.imgur.com/MRKBDbx.png  It was a big big problem since the pop up completelly stopped the conversion to dng. Also it doesn't seem that any frame was actually corrupted, this happened on various spots and then I came back and exported the "problematic" frame without any issue. Are other pass tried if a frame fail to save? Or is it like done once and if it doesn't work it is over? There should be an option to not stop and just export a log with problematic frames.

2) MAPP batch creation.
I couldn't find this, for me it seems obvious that the point of a MAPP file is to make "end of the day" playback easy, it should be possible to batch the creation of the files so that you can progress through clips without stopping.

3) Playback is 5 fps for me. I have an i7 2.3 2012 and dedicated GPU, I'm not sure if this is to be expected, good to remember that MlRawViewer has real time!

4) The software still has a general feeling of "beeing stuck" when performing complex actions, there're many instances where it happens. This is a problem for daily use, it is nerve breaking.

5) Multhithread kicking in when not needed. This need further experimentation, I remember you saying that multithread kicks in only when raw corrections are applayed but I don't think that is true. And even so raw correction where possible at the same speed even before multithread. I'm curious to know what other people experience is on this. For me it is a real problem since that much power consumption for years/conversion nights will damage the internal of macbooks :/

6) FPS export speed should be displayed on the export window, it is a very usefull feature to test/monitor/report stuff.

7) Hidable (in the dock) export window. A small feature that I'm not sure if it is easy to implement or not.

8) Highlight recovery. I've putted this on the end since at the moment I'm still thinking of using Davinci Resolve from dng export. But I'm amazed at the improvements in color rendition. The ease of use in switching between different linear to gamma elaboration is remarquable. The tonemapped default one is very good, good skin colours. Curious to know where did you take the curve (gamma as well?) data from for this.
Anyways Highlight recovery is not even near as good as other options, and I would say this is fairly important if you want to export and use ProRess directly from MLV App. HEre there is a comparison, I've changed the gamma scheme on Resolve to make the difference pop up even more. The highlight reconstruction option in MLV App makes no difference. https://imgur.com/a/0CGFw4p





masc

Thanks for your report, togg.
1) Maybe bouncyball can tell something about that...

2) MAPPs are batch created when exporting files (e.g. if you export proxy for all files first) or for single file (non batch) if you just open it.

3) MLVApp don't uses any GPU. That is why it works on nearly every computer, instead of most other software. If you use it on a non-retina display it should be ~1.5x faster. If you need faster preview, export the clip or use MlRawViewer. Compairing to MlRawViewer is not really fair, because of the lack of many many functions. Resolve on my systems has the same speed (more or less) and heats the GPU additionally.
For FHD on a MBP 2013 i5 2.4GHz I get 13fps, on a MBP 2010 Core2Duo 2.4GHz 7fps, on a iMac 2011 i5 21.5" 23fps.

4) ?! = 3)?

5)
QuoteMulthithread kicking in when not needed.
I don't think so. Multithreading is no fun, so we implemented it only where it is needed.
QuoteAnd even so raw correction where possible at the same speed even before multithread.
And that's also not true. We benchmarked it often enough I think.
Complete processing pipeline, most debayers and a part of RAW corrections use multithreading, as well as ffmpeg.

6) Really? For what reason is that useful? Use the fps label from playback. The pipeline is identical, only the output is viewer vs. ffmpeg/AVFoundation.

7) I did not find any possiblity to realize that. We can chose between:
   a) Window is not at OS foreground, but will be lost after first click somewhere in your OS
   b) What we have
   Maybe someone knows programming with Qt and can help...
Edit: yay... I finally found another solution after searching for it the 1000th time.

Highlights: Have you tried: exposure -2, lighten +50, highlight recovery on? For me, this mostly looks better than Resolve.
5D3.113 | EOSM.202

bouncyball

Hi guys,

@togg

1) I really need that MLV to reproduce this error. I wrote this error handling and sadly never could reproduce this exact error in real life :P so I'm really interested to play with it. BTW are you trying to save losslessly compressed DNGs?

2) Yeah... MAPP is created when MLV fully read not just opened to generate preview thumb. After loading the MLV just once, accessing next time(s) to this exact clip is very fast. Actually batch saving of the MAPPs, as a separate action in the menu, is doable. Maybe we'll think about it with @masc.

3) Yeah we do not use GPU. Reason: if we do so we have to implement all processing pipeline (not only debayer) also on GPU, it's tough! Look at "fastcinemadng" it uses expensive external library which does lots of stuff on GPU in pure Nvidia's CUDA. Also look at the evolution of the MLRawViewer. I mean compare 1st commit to the last one and you will see how it grew from just one opengl shader to 6 or 7 including basic processing and minimalistic but cool GUI :)

regards
bb

megapolis

@bouncyball
I need to do some clarification here. In Fast CinemaDNG we are using our own CUDA library for image processing, that we've implemented by themselves. Yes, this is quite complicated, but we think it's worth doing.
P.S. Sorry for intrusion. MLVApp is very good application, we have no doubts about that.

bouncyball

@megapolis

Thanks for the clarification :) I like your cool app and it works smoothly on my GTX1080. I just miss the Linux version.

Lars Steenhoff

And I miss the Mac version ( I know cuda needs nvida, but recent macs can have those cards with external gpu)

The same for MLVapp I would love to see and gpu accellerated version, or a new version that uses caching for smooth playback on the second loop.

masc

Quote from: Lars Steenhoff on December 11, 2018, 08:48:44 AM
The same for MLVapp I would love to see and gpu accellerated version...
You shouldn't wait for that. Start implementing it and help us. Until now nobody was willing to do that for us and we don't know writing GPU code. It is very different... and has to be learned.

Quote from: Lars Steenhoff on December 11, 2018, 08:48:44 AM
... or a new version that uses caching for smooth playback on the second loop.
We'll see what we can do here. But it has not highest priority. Implementing this was very painful in the past (never worked fine on Windows) and it will become ~100% more complex to how it was before in terms of cache organization. Current status can be found on github issue page.
5D3.113 | EOSM.202

togg

Quote from: masc on December 10, 2018, 09:29:13 AM
Thanks for your report, togg.
1) Maybe bouncyball can tell something about that...

2) MAPPs are batch created when exporting files (e.g. if you export proxy for all files first) or for single file (non batch) if you just open it.

3) MLVApp don't uses any GPU. That is why it works on nearly every computer, instead of most other software. If you use it on a non-retina display it should be ~1.5x faster. If you need faster preview, export the clip or use MlRawViewer. Compairing to MlRawViewer is not really fair, because of the lack of many many functions. Resolve on my systems has the same speed (more or less) and heats the GPU additionally.
For FHD on a MBP 2013 i5 2.4GHz I get 13fps, on a MBP 2010 Core2Duo 2.4GHz 7fps, on a iMac 2011 i5 21.5" 23fps.

4) ?! = 3)?

5)  I don't think so. Multithreading is no fun, so we implemented it only where it is needed. And that's also not true. We benchmarked it often enough I think.
Complete processing pipeline, most debayers and a part of RAW corrections use multithreading, as well as ffmpeg.

6) Really? For what reason is that useful? Use the fps label from playback. The pipeline is identical, only the output is viewer vs. ffmpeg/AVFoundation.

7) I did not find any possiblity to realize that. We can chose between:
   a) Window is not at OS foreground, but will be lost after first click somewhere in your OS
   b) What we have
   Maybe someone knows programming with Qt and can help...
Edit: yay... I finally found another solution after searching for it the 1000th time.

Highlights: Have you tried: exposure -2, lighten +50, highlight recovery on? For me, this mostly looks better than Resolve.


Quote from: bouncyball on December 10, 2018, 06:22:41 PM
Hi guys,

@togg

1) I really need that MLV to reproduce this error. I wrote this error handling and sadly never could reproduce this exact error in real life :P so I'm really interested to play with it. BTW are you trying to save losslessly compressed DNGs?

2) Yeah... MAPP is created when MLV fully read not just opened to generate preview thumb. After loading the MLV just once, accessing next time(s) to this exact clip is very fast. Actually batch saving of the MAPPs, as a separate action in the menu, is doable. Maybe we'll think about it with @masc.

3) Yeah we do not use GPU. Reason: if we do so we have to implement all processing pipeline (not only debayer) also on GPU, it's tough! Look at "fastcinemadng" it uses expensive external library which does lots of stuff on GPU in pure Nvidia's CUDA. Also look at the evolution of the MLRawViewer. I mean compare 1st commit to the last one and you will see how it grew from just one opengl shader to 6 or 7 including basic processing and minimalistic but cool GUI :)

regards
bb


1) I wish I could provide that MLV, problem is it is very big. I'm not even sure I could reproduce this every time, it happened multiple times in random spots, I couldn't test preciselly. Yes I'm trying to save to losslessly compressed DNG from 14bit compressed MLV. Also note that I'm talking about a 250GB total export batch, around 10 takes total.
But I do feel like it's important we get around this, since the conversion time is so big having one of this failures during night conversion and having some CF cards not ready for next day is quite catastrophic.
Is MLV App trying multiple times if a frame give out errors? Could this be related to drive I/O errors? Weird though, since hard drives were still connected.

2) Exactly. I really feel that batch saving MAPP is important, having to wait for take to load and click at the end of a shooting day is impossible. Better to launch a batch, eat something, and come back in 4 minutes.
Also the opening with MAPP file is still a little bit long I'd say, 1 second and something? But I guess it can't be brought down easely.

3) Got this. At the end of it I understand the difficulty of bringing real time playback, it doesn't matter that much and sadly there're not enough users to justify that much writing of code, I'll still have MlRawViewer on the dock.
But I've noticed something I don't fully understand. FPS change from 4 to 8 if I resize the window. 10 if I check "open in low resolution". Is this due to retina, @masc? Also my numbers seem pretty low compared to yours, what could be the problem beside retina?

7) Nice! For me the omni present export window isn't the biggest deal but makes the software a little bit too intrusive and "clunky".


8) I've tried your method for Highlight reconstruction. I must admit that playing that much with sliders scare me a bit. Interesting tough. I have the feeling the whole highlight reconstruction is a very complex deal, even Resolve can't handle it well and you have to play with white balance on raw panel to avoid artifacts. For me it is a badly needed feature though, I didn't measure it but it is at least one stop more of exposure.

I've uploaded 2 small MLV files yo play with that you can use to see where and how MLVApp still fails.

http://www.mediafire.com/file/v2cu6bzenxg9rft/M07-1108.MLV/file


http://www.mediafire.com/file/4l9ibbg7tvp0g1g/M07-1108-2.MLV/file


Thanks for all the help!

masc

@togg: I played with your MLVs and get this out of it:


See the sliders. I had to adjust the RAW white level to get a correct sky. Indeed, highlight processing is very complicated. It just works, if the white level is set correctly. The value read out from the MLV might be wrong, what leads to strange colors in overexposed areas.

For framerate: the more (screen)pixels the software has to calculate, the longer it needs. So if the window is small, it will be faster. Retina or other highres screens are very bad, because more pixels (4x @ retina) have to be calculated. OSX does this in background without the need of further code, so we can't do much here.
Maybe the screen is the difference between your numbers and mine: my screens are mostly around FHD, the old MBP has 1280x800.
Another speed brake is "lossless". Not using it can bring up to 2x more speed, because decoding is not needed.
5D3.113 | EOSM.202

bouncyball

@togg

Quote from: togg on December 11, 2018, 02:08:54 PM
Yes I'm trying to save to losslessly compressed DNG from 14bit compressed MLV. Also note that I'm talking about a 250GB total export batch, around 10 takes total.
Is MLV App trying multiple times if a frame give out errors? Could this be related to drive I/O errors? Weird though, since hard drives were still connected.
Lossless compressor fails sometimes (and there is nothing I can do about it). The encoder spits out error and it means the data can not be encoded efficiently (e.g. compressed data is even larger then original ;))
And yes this error also occurs due to I/O issues.
Please try to export uncompressed DNGs (it is working every time) and report back.

Quote from: togg on December 11, 2018, 02:08:54 PM
Also the opening with MAPP file is still a little bit long I'd say, 1 second and something? But I guess it can't be brought down easely.
Well... if the clip is long enough and includes audio then yes (w/o audio almost no time needed).

bouncyball

BTW I've added MLV decompression option to mlvapp recently. So you can easily uncompress any MLV and play it even with good old unmodified MLRawViewer. I can play 3K+ MLVs in real time w/o issues.

bouncyball

Even better with mlvapp's HSL correction and gradient tool ;)



I guess left side of the sky is really unrecoverable.

togg

Quote from: masc on December 11, 2018, 02:55:30 PM
@togg: I played with your MLVs and get this out of it:


See the sliders. I had to adjust the RAW white level to get a correct sky. Indeed, highlight processing is very complicated. It just works, if the white level is set correctly. The value read out from the MLV might be wrong, what leads to strange colors in overexposed areas.

For framerate: the more (screen)pixels the software has to calculate, the longer it needs. So if the window is small, it will be faster. Retina or other highres screens are very bad, because more pixels (4x @ retina) have to be calculated. OSX does this in background without the need of further code, so we can't do much here.
Maybe the screen is the difference between your numbers and mine: my screens are mostly around FHD, the old MBP has 1280x800.
Another speed brake is "lossless". Not using it can bring up to 2x more speed, because decoding is not needed.

Very interesting, so the white level slider is what Resolve is missing. Still a lot of slider though, kind of scary to start a grade from that much movement, but I'm starting to see this as needed. Still strange that for the highlight recovery button to kick in you have to lower the exposure and in some way affect the whole image. some more informations can be seen on resolve: https://i.imgur.com/jhUgocW.png

Damn, that's why they put a open in lower resolution in the first place, I think I'll use it. There's not that much text on screen.

I'll test uncompressed speeds again when possible! Thanks.

Quote from: bouncyball on December 11, 2018, 04:30:47 PM
@togg
Lossless compressor fails sometimes (and there is nothing I can do about it). The encoder spits out error and it means the data can not be encoded efficiently (e.g. compressed data is even larger then original ;))
And yes this error also occurs due to I/O issues.
Please try to export uncompressed DNGs (it is working every time) and report back.

Thing is those clips/frames didn't actually have any problem. I came back to it a second time and they exported fine. This is why I was wondering if the software could keep trying if it fails once, in both cases of I/O or compression issues.

Fantastic for the uncompression, always usefull to have!

masc

Quote from: togg on December 12, 2018, 01:19:37 AM
Still strange that for the highlight recovery button to kick in you have to lower the exposure and in some way affect the whole image.
Highlight reconstruction in MLVApp does only reconstruct highlights and does not affect some brightness as in Resolve. That means, areas where the green channel was clipped (99% of damaged highlights) the green channel is recovered from red and blue. Clipped green with lowered exposure leads to pink highlights.
OFF:


ON:


Quote from: togg on December 12, 2018, 01:19:37 AM
some more informations can be seen on resolve: https://i.imgur.com/jhUgocW.png
Hm... slightly more contrast, but wrong colors (cyan to magenta in the upper right).

Quote from: togg on December 12, 2018, 01:19:37 AM
Damn, that's why they put a open in lower resolution in the first place, I think I'll use it. There's not that much text on screen.
Where do you find this? Is the App somehow opened in LowRes then? If it is just the simulated resolution in OSX: this doesn't make it any better, because rendered area (in cm) on screen is more or less the same.
5D3.113 | EOSM.202

togg

Quote from: masc on December 12, 2018, 08:03:32 AM
Where do you find this? Is the App somehow opened in LowRes then? If it is just the simulated resolution in OSX: this doesn't make it any better, because rendered area (in cm) on screen is more or less the same.


it is the option that you have in the Finder info for the software and yes it is working, I've tested it only with small files but I'm almost sure of it.

OK got the whole process of highlight, interesting. I guess that affecting the whole image is a good solution to avoid artifacts on edges, also writing a super powerfull highlight reconstruction button would maybe take time.

masc

Quote from: togg on December 12, 2018, 10:03:35 AM
it is the option that you have in the Finder info for the software and yes it is working, I've tested it only with small files but I'm almost sure of it.
GREAT! Never saw this one! That indeed works! :D
5D3.113 | EOSM.202

70MM13

Is it possible to make an option for the edit area to be in a window/info box/whatever nomenclature as a floating window?

This would be great for multiple monitors!

togg

Quote from: masc on December 12, 2018, 11:57:15 AM
GREAT! Never saw this one! That indeed works! :D

Yes, for me it goes from 5 fps to 7-8.
I couldn't find the option to decompress MLV, is it already in?

masc

Quote from: togg on December 13, 2018, 12:25:35 PM
Yes, for me it goes from 5 fps to 7-8.
I couldn't find the option to decompress MLV, is it already in?
For this you'll have to compile yourself, or wait for next release...

@70MM13: there are many many dependencies between all panels in the frame... relatively easy would be adding a 2nd window, which shows the viewer a 2nd time. But this again costs some fps...
5D3.113 | EOSM.202

70MM13

If it's not too much trouble to add the option, it would be great!

Having a fullscreen viewer is great for critical grading. FPS is irrelevant when working with a still frame, and if one needs every ounce of playback speed, just disable the extra window...

PS: I'm happier with mlvapp than resolve for great results and much better control system!

Thanks for such a great app that just keeps getting better!

PPS: is there a way to define the output filenames when doing an bunch of clips, such as naming each clip in the editor?  I don't see any obvious way to do it...


masc

Quote from: 70MM13 on December 13, 2018, 07:37:46 PM
Having a fullscreen viewer is great for critical grading.
Fullscreen is not possible - unfortunately Qt is very buggy here. I implemented it a year ago using the Qt fullscreen functions. But it is hidden since that because it works really bad. It was bug free on OSX single monitor systems. On some other systems all input devices get blocked in fullscreen and you just can shut up the app... if you have more than one monitor, it was even more strange. That's why also another extra window would not be fullscreen. The closest you can get is pressing "A S E" and maximizing the app.
And here again: if there is someone who can help me with such Qt problems: please contact me!

Quote from: 70MM13 on December 13, 2018, 07:37:46 PM
PPS: is there a way to define the output filenames when doing an bunch of clips, such as naming each clip in the editor?  I don't see any obvious way to do it...
Nope. Renaming is only possible if you export one clip.

Quote from: 70MM13 on December 13, 2018, 07:37:46 PM
PS: I'm happier with mlvapp than resolve for great results and much better control system!
:D thank you. We do our very best...
5D3.113 | EOSM.202

70MM13

Since I always shoot in 2.35:1, I call it "fullscreen" to get rid of the boxes on left and right ;)

So, having the edit area in a floating window on another screen is just perfect for me!

masc

Quote from: 70MM13 on December 13, 2018, 09:27:57 PM
So, having the edit area in a floating window on another screen is just perfect for me!
I made the edit area floatable and moveable now. But I have no idea, what bugs this brings. So please - who is able to compile - test it carefully.

5D3.113 | EOSM.202