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

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

Previous topic - Next topic

0 Members and 9 Guests are viewing this topic.

ilia3101

Quote from: Luther on September 26, 2019, 09:19:40 AM
@Ilia3101 I think the Rec.709 matrix is wrong. According to the ACES github, the XYZ>Rec.709 matrix is this:But on MLVAPP processing.c it is:Not sure which one is correct.

Also, I have a request. Can you add AP1 to the Gamuts? This seems to be the matrix:

Hm, looks like ours is less decimal places, not a problem, but two of the bottom numbers are actually different. Strange. I got it off Wikipedia, I'll try to find the original rec709 specs and see what it is.

And sure, will add AP1

visionbyeric

Hello, The MLV App is best ML Raw app for my work flow. Unfortunately I downloaded the newest version 1.9 and soon as I import a MLV file, it crashes. Version 1.8 runs flawlessly. I'm running Windows 10 64 1903.

masc

Quote from: visionbyeric on October 05, 2019, 07:12:33 AM
... the newest version 1.9 and soon as I import a MLV file, it crashes. Version 1.8 runs flawlessly. I'm running Windows 10 64 1903.
We still need someone with a Win-PC where MLVApp crashes, who installs Qt+Debugger and who tells us the crashing line of code. Without that information we are not able to fix this. On all my computers this crash does not happen, so I don't know what is going on there.
5D3.113 | EOSM.202

Luther

I cannot reproduce the crash here on Windows 10. Neither the slowness reported by others.
This happens in any MLV file @visionbyeric ? Or only with MLV file with sound? If you can, send me a file (I don't record audio in MLV).

masc

For everybody who is able to compile MLVApp: please test latest revision. I removed all ffmpeg rescale functions and therefor added AVIR rescaling for ffmpeg export. It would be important, if you could test this and post issues. It was a big change and the scaling was linked into many parts of the export. I just hope I haven't forgotten something... ;) There are hundreds of possible export setting combinations.
5D3.113 | EOSM.202

DeafEyeJedi

Quote from: masc on October 11, 2019, 08:45:21 PM
For everybody who is able to compile MLVApp: please test latest revision. I removed all ffmpeg rescale functions and therefor added AVIR rescaling for ffmpeg export. It would be important, if you could test this and post issues. It was a big change and the scaling was linked into many parts of the export. I just hope I haven't forgotten something... ;) There are hundreds of possible export setting combinations.

Okie dokie. Just updated to Catalina. Will compile and give it a ride.
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

visionbyeric

I will try and set up Qt+Debugger and see what I can find.

Thank You

masc

5D3.113 | EOSM.202

masc

Quote from: DeafEyeJedi on October 12, 2019, 06:42:59 AM
Okie dokie. Just updated to Catalina. Will compile and give it a ride.
Great. Did not try on Catalina yet. Hopefully it works!
5D3.113 | EOSM.202

DeafEyeJedi

Compiled and running flawlessly on Catalina so far. Question though how do I confirm that it is actually exporting w the new algorithm re: AVIR? :)
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

masc

Quote from: DeafEyeJedi on October 13, 2019, 08:26:17 AM
Compiled and running flawlessly on Catalina so far. Question though how do I confirm that it is actually exporting w the new algorithm re: AVIR? :)
Good to know, thanks.
If you get resized clips when exporting with AVFoundation or ffmpeg with latest revision, you used AVIR. From now on it is the only algorithm...
5D3.113 | EOSM.202

escho

Quote from: masc on October 11, 2019, 08:45:21 PM
For everybody who is able to compile MLVApp: please test latest revision...

Doesn´t compile here on openSUSE Tumbleweed, not shure why. Creating the stash-file works, compiling not. I will have a look at it later, what´s going on.
Edgar
https://sternenkarten.com/
600D, 6D, openSUSE Tumbleweed

ilia3101

Quote from: DeafEyeJedi on October 13, 2019, 08:26:17 AM
Compiled and running flawlessly on Catalina so far. Question though how do I confirm that it is actually exporting w the new algorithm re: AVIR? :)

Same! (on mojave and ubuntu)

Quote from: escho on October 13, 2019, 12:52:43 PM
Doesn´t compile here on openSUSE Tumbleweed, not shure why. Creating the stash-file works, compiling not. I will have a look at it later, what´s going on.
Edgar

Compiles fine for me on Ubuntu with "qmake; make -j4"

escho

Quote from: Ilia3101 on October 13, 2019, 01:05:20 PM
Compiles fine for me on Ubuntu with "qmake; make -j4"

I found the error.
I use a little bash-script for cloning, compiling and installing MLV App. I used the wrong copy of this script, which had an "exit" before the "make" (for debugging reasons).

Compiling with the correct script worked without problems. Exporting to uncompressed avi with resizing worked too :)

It looks like the default for resizing is 1920x1080px. Maybe, it´s better to have the native resolution of the MLV as default.  ( I often use uncommon aspect-ratios for my astronomy stuff)
https://sternenkarten.com/
600D, 6D, openSUSE Tumbleweed

masc

Quote from: escho on October 13, 2019, 01:33:27 PM
It looks like the default for resizing is 1920x1080px. Maybe, it´s better to have the native resolution of the MLV as default.  ( I often use uncommon aspect-ratios for my astronomy stuff)
Default is "no rescaling" -> so native resolution. You have to uncheck "resize" in export settings for that. Does that work for you?
5D3.113 | EOSM.202

escho

Quote from: masc on October 13, 2019, 03:13:27 PM
Default is "no rescaling" -> so native resolution. You have to uncheck "resize" in export settings for that. Does that work for you?

Played a bit with it:  :)

"No resizing" is the default and this works fine. And "resizing" works fine as well.

The reason for my confusion was these two points

1. The displayed resolution has no default. It´s always the latest choosen resizing resolution (maybe from days before). Reset receips does not change anything here.
If I import a MLV into a new session, I would expect to see the native resolution of the MLV in the resizing fields as a starting point.

2. Locking the aspect ratio for the resizing fields is a great feature. The height-field is grayed out then and the resulted resolution is calculated from the width-field.
That works fine, but the height-field isn´t updated with the calculated height.

That´s just for info
Edgar
https://sternenkarten.com/
600D, 6D, openSUSE Tumbleweed

masc

Quote from: escho on October 13, 2019, 05:04:10 PM
1. The displayed resolution has no default. It´s always the latest choosen resizing resolution (maybe from days before). Reset receips does not change anything here.
If I import a MLV into a new session, I would expect to see the native resolution of the MLV in the resizing fields as a starting point.

2. Locking the aspect ratio for the resizing fields is a great feature. The height-field is grayed out then and the resulted resolution is calculated from the width-field.
That works fine, but the height-field isn´t updated with the calculated height.
Thanks for testing and reporting.
These two points have a reason: the MLVs you import might have the same resolution (as I expect you use it)... but nobody can garantue that. That is why it has to be universal for projects with clips of different resolutions. And in such a project... which resolution is the one to set into this dialog window?
5D3.113 | EOSM.202

Luther

@masc Tested on Windows 10. Couldn't try all possible "permutations", but I've tested on all codecs. It's working flawlessly, even for 4x resize.
Some notes I took while testing:
- FFmpeg Anatolyi doesn't work (can't be selected)
- Is the "CLancIR class" (Lanczos) difficult to implement? According to the AVIR github, "LANCIR offers up to 200% faster image resizing". Might be useful for some people that need faster conversion.
- The avir.h seems to linearize sRGB gamma... doesn't it conflict with other color conversions?
- Stretch transformation is using AVIR? I've tested and it's working too.
- Why use bt601 in:
resizeFilter = QString( "-vf %1scale=in_color_matrix=bt601:out_color_matrix=bt709%2%3 " )
Instead of bt2020?
resizeFilter = QString( "-vf %1scale=in_color_matrix=bt2020:out_color_matrix=bt709%2%3 " )
This way you're going from a bigger to smaller space, which is the "correct". I've tested and there's a small change in chroma noise from what I could notice...

While testing AVIR, I also changed the AP0 matrix to the AP1 in processing.c:

1.6410233797, -0.3248032942, -0.2364246952
-0.6636628587, 1.6153315917, 0.0167563477
0.0117218943, -0.0082844420, 0.9883948585


This gave me the best color results so far. Please test it too...

cmh

Everything's working fine on windows 10 except when the Resize box isn't ticked in the Export Settings.
On an anamorphic 5k shot, if this box isn't ticked I got a shorter video which is a 3x3 mosaic of the shot.

a1ex

Small bug (?) report.

While trying to identify the root cause of these artifacts, I've noticed I'm unable to identify ML version used for the original recording. The sample clip shared there appears to be exported from MLV App, and this is the only VERS block I could find:


Block: VERS
  Offset: 0x0000023c
  Number: 8
    Size: 40
    Time: 18446744073709552.000000 ms
  String: 'MLV App version 1.9'


Normally, mlv_rec/mlv_lite are saving extended version info (multiple VERS blocks) about ML core version, alongside with info about modules loaded, including the version of each module.

Based on this, I'd say the preferred way to handle VERS blocks while transcoding is to add the app-specific block on top of existing ones.

masc

Thank you for testing Luther!
Quote from: Luther on October 15, 2019, 01:56:22 AM
- FFmpeg Anatolyi doesn't work (can't be selected)
This should only be the case for ProRes4444. Anatolyi does not offer this kind of export. Did you had this for other codecs?
Quote from: Luther on October 15, 2019, 01:56:22 AM
- Is the "CLancIR class" (Lanczos) difficult to implement? According to the AVIR github, "LANCIR offers up to 200% faster image resizing". Might be useful for some people that need faster conversion.
In principle it should be the same interface as for AVIR. But they write it is 8bit only. So we would loose a lot of information. And they write that it is not thread safe. No idea what that means exactly... but if multithreading doesn't work with it, 200% on single core will just be ~50%  on quad core.
Quote from: Luther on October 15, 2019, 01:56:22 AM
- The avir.h seems to linearize sRGB gamma... doesn't it conflict with other color conversions?
I think that input color space = output color space. At least I don't see any difference in color.
Quote from: Luther on October 15, 2019, 01:56:22 AM
- Stretch transformation is using AVIR? I've tested and it's working too.
Yes. Fine. But another user reported a bug on github about that. When resize=off but stretching=on (e.g. anamorphic footage) and using ffmpeg, we exported a 3x3 matrix of the clip. Should be fixed now.
Quote from: Luther on October 15, 2019, 01:56:22 AM
- Why use bt601 in:
resizeFilter = QString( "-vf %1scale=in_color_matrix=bt601:out_color_matrix=bt709%2%3 " )
Instead of bt2020?
resizeFilter = QString( "-vf %1scale=in_color_matrix=bt2020:out_color_matrix=bt709%2%3 " )
This way you're going from a bigger to smaller space, which is the "correct". I've tested and there's a small change in chroma noise from what I could notice...
ffmpeg interprets all input as bt601. This part of the code tells ffmpeg, that we rendered bt709. You clearly see the difference in color when commenting this part. As the code is, the colors you'll get in your exported clip will be as you saw them in the viewer.
Quote from: Luther on October 15, 2019, 01:56:22 AM
While testing AVIR, I also changed the AP0 matrix to the AP1 in processing.c:

1.6410233797, -0.3248032942, -0.2364246952
-0.6636628587, 1.6153315917, 0.0167563477
0.0117218943, -0.0082844420, 0.9883948585

This gave me the best color results so far. Please test it too...
Cool. Should be easy to add another option with this matrix.


@a1ex: puh... no idea about, sry. This part was implemented by bouncyball, if I remember right. I'll create an issue on github to not forget about. From what I see in the code, we really just save what you posted.
5D3.113 | EOSM.202

2blackbar

I bought better quality monitor and i see that id like to get more control over h.264 and 265 compression besides medium high and low quality, will it ever be possible to have a number so we could input our values for export quality ? Some shots i need more and some less, but gap between high and medium h264 is quite big, 50 seconds is 31mb for medium and 300mb for high.100mb for high quality h265, but id like about 60mb.
I asked this before , is there a way to export with our own h264 quality maybe with some command line ?

Luther

Quote from: masc on October 15, 2019, 08:26:42 PM
This should only be the case for ProRes4444. Anatolyi does not offer this kind of export. Did you had this for other codecs?
That's right, my fault.
Quote
In principle it should be the same interface as for AVIR. But they write it is 8bit only. So we would loose a lot of information. And they write that it is not thread safe. No idea what that means exactly... but if multithreading doesn't work with it, 200% on single core will just be ~50%  on quad core.
I think they mean that it might have racing conditions. Don't think it affects the performance, but it might be buggy.
Quote
I think that input color space = output color space. At least I don't see any difference in color.
Yes, not sure why they do this (from avir.h):

/**
* Function approximately linearizes the sRGB gamma value.
*
* @param s sRGB gamma value, in the range 0 to 1.
* @return Linearized sRGB gamma value, approximated.
*/

template< class T >
inline T convertSRGB2Lin( const T s )
{
const T a = (T) 0.055;

if( s <= (T) 0.04045 )
{
return( s / (T) 12.92 );
}

return( pow24_sRGB(( s + a ) / ( (T) 1 + a )));
}

/**
* Function approximately de-linearizes the linear gamma value.
*
* @param s Linear gamma value, in the range 0 to 1.
* @return sRGB gamma value, approximated.
*/

template< class T >
inline T convertLin2SRGB( const T s )
{
const T a = (T) 0.055;

if( s <= (T) 0.0031308 )
{
return( (T) 12.92 * s );
}

return(( (T) 1 + a ) * pow24i_sRGB( s ) - a );
}


Quote
Yes. Fine. But another user reported a bug on github about that. When resize=off but stretching=on (e.g. anamorphic footage) and using ffmpeg, we exported a 3x3 matrix of the clip. Should be fixed now.

Tested now, it's working (with your last commit).

Quote
ffmpeg interprets all input as bt601. This part of the code tells ffmpeg, that we rendered bt709. You clearly see the difference in color when commenting this part. As the code is, the colors you'll get in your exported clip will be as you saw them in the viewer.
Got it.

Luther

Quote from: 2blackbar on October 15, 2019, 10:36:40 PM
I bought better quality monitor and i see that id like to get more control over h.264 and 265 compression besides medium high and low quality, will it ever be possible to have a number so we could input our values for export quality ? Some shots i need more and some less, but gap between high and medium h264 is quite big, 50 seconds is 31mb for medium and 300mb for high.100mb for high quality h265, but id like about 60mb.
I asked this before , is there a way to export with our own h264 quality maybe with some command line ?

Would be nice to be able to choose the --crf value and -preset option. +1

DeafEyeJedi

5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109