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.

Messages - masc

Pages: [1] 2 3 ... 53
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

Commandline is no good idea. One single wrong or unexpected symbol brings the whole thing to crash. If you like other options, you could change the numbers in source code and compile. This is the simplest, fastest and safest way to get what you want.
Changing parameter elements dynamically in dependency to codec is extremely overkill IMO.

Thank you for testing Luther!
- 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?
- 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.
- 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.
- 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.
- Why use bt601 in:
Code: [Select]
resizeFilter = QString( "-vf %1scale=in_color_matrix=bt601:out_color_matrix=bt709%2%3 " ) Instead of bt2020?
Code: [Select]
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.
While testing AVIR, I also changed the AP0 matrix to the AP1 in processing.c:
Code: [Select]
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.

General Development Discussion / Re: The MLV format
« on: October 14, 2019, 08:13:49 PM »
Thanks. I will try using that for something. I have a command program thing that is simple C, won't use it for that, as it really would be overkill. But there will be more than one program with libMLV so it could come in useful. Definitely going to use Qt for the GUI app.
If you like to try with Qt, this would be your .pro file:
Code: [Select]
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt

SOURCES += read_raw.c \
    camera_matrices.c \
    raw2mlv.c \
    ../LibMLV/MLVFrameUtils.c \

    ../LibMLV/LibMLV.h \
    ../LibMLV/mlv_structs.h \
    ../LibMLV/MLVFrameUtils.h \
Shouldn't be much overkill, because it just uses the compiler and nothing else for building. But it is nice to handle, because you can use QtCreator's editor and buttons to compile - so much comfort.

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?

General Development Discussion / Re: The MLV format
« on: October 13, 2019, 04:10:18 PM »
Yapp, exactly. I am just not 100% sure if that works without Qt libs - this would be overkill. To be tested...

Edit: if you open QtCreator -> new project -> non-qt project -> Plain C/C++ Application..." This should do the job for Win/Linux/OSX.

General Development Discussion / Re: The MLV format
« on: October 13, 2019, 03:39:47 PM »
Qt for the converter GUI yes, I agree.
Qt is not just GUI. You can also build command line tools in Qt.

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?

General Development Discussion / Re: The MLV format
« on: October 13, 2019, 03:11:23 PM »
Also would like advice/help on compiling methods. Want it  to work on Windows too.
If you like to have it working on all platforms with mostly one code base: Qt is again our best friend ;)
You wrote it again in C/C++?

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

Okie dokie. Just updated to Catalina. Will compile and give it a ride.
Great. Did not try on Catalina yet. Hopefully it works!

I will try and set up Qt+Debugger and see what I can find.
Thumbs up! This would be fantastic!

Camera-specific discussion / Re: Canon EOS M
« on: October 12, 2019, 08:14:40 PM »
when I use MLVApp to export 5Kf full sensor readout footage, the final exported file is just 1KB, does anyone meet this problem?
This is off-topic here. Post this in the MLVApp thread and describe what you did exactly.

General Development Discussion / Re: The MLV format
« on: October 11, 2019, 10:15:36 PM »
Wicked! What have you done?  ;D

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.

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

Camera-specific discussion / Re: Canon EOS M
« on: October 06, 2019, 10:13:06 AM »
... I was just complaining about the long export times to ProRes.
Exporting 1:45 to ProRes 422 takes more or less around 3 hours.
Exporting 1:45 to DNG (with small adjustments done to the raw) takes 4 minutes.
You mean minutes or hours (1:45)? I am back home and render my holiday clips from the last 2 weeks with my old iMac 2011: 380GB MLVs, 430 clips, rendered with some basic adjustments in 9h30min to ProRes422. I still don't think that this is extremely long for that amount of data. I still more think something is wrong with your computer or configuration.

Camera-specific discussion / Re: Canon EOS M
« on: October 05, 2019, 10:25:46 AM »
@turnlemons2lemonade: it is still off-topic here (that's why I wrote "post in the MLVApp thread"). Anyway...
If I do exactly the same as you described, a 10sec clip needs 2:30min here on my 9 years old Core2Duo (dual core), on my iMac 2011 I mostly get more than the double speed as from this Core2Duo. So something is strange with your system.

"Quick" depends on what you are doing after this export. DNG export is quick, yes, but after this, processing starts and is slow again. Davinci needs more or less the same time on my computers like MLVApp (but I don't have a monster GPU - sure it would be faster if you have one). DNG Fast Pass export in MLVApp is fastest, because no RAW Correction is applied (e.g. Focus Pixels will still be there).

Sure... grading in FCPX is fast, therefor you'll get artifacts as described. I recommend to grade in one step - so from MLV to final-color or from DNG to final-color.

Camera-specific discussion / Re: Canon EOS M
« on: October 04, 2019, 10:19:24 PM »

"I would not really grade in FCPX, because quality is sooo bad in comparison."

In comparison to what ? Please ~
Grading in MLVApp offers a 16bit pipeline (which should be mostly used after WB correction and tonemap). After exporting to ProRes a lot of (bitdepth) information is lost forever. When grading now in any NLE, you'll get easily artifacts and banding. Using FCPX those artifacts are visible in most cases. At least on my machines FCPX grading could never satisfy.

Camera-specific discussion / Re: Canon EOS M
« on: October 04, 2019, 08:47:29 PM »
Working with MLV App
MLVApp works better for scanning the RAW video BEFORE applying corrections / processing so I can scan a video and see if it's good, if not delete it and AFTER process it for export.
I love the results coming out of this app, basically just using the Rec709 conversion and white balance picker & some sharpen. After that I pull the video in FCPX and grade it there, as FCPX is much more responsive with MOV.

Sometimes MLV App just froze when exporting clips, so better to just export 5 clips at a time if longer and quit the app and come back. Yeah, not the best experience but it is what it is.


I did get a 1:35 min clip using 10bit, monitor OFF without any dropframes, looking great. Exporting RAW to ProRes for this takes 45 minutes though. That would not be a problem, however sometimes after this long export times MLVApp just stops responding and you basically loose the export too. So that's why I think it's better to do the cuts in camera if possible, or at least as close as you can & keep everything short.

What are you doing? Do you use DualIso or is your PC running on extremely low power? For >450GB MLV (90min, 350 clips) my 8 years old computer needed 12h for rendering to ProRes via MLVApp... can't believe that your computer needs so long for that few seconds clips. I also never got a crash or freeze with that. If you get crashes/freezes, please post into MLVApp thread how to reproduce. Without such information it won't become better.

I would not really grade in FCPX, because quality is sooo bad in comparison.

Post-processing Workflow / Re: Quickest Way From MLV to Davinci Resolve
« on: October 03, 2019, 04:38:48 PM »
... and couldn't find the best way to import into Davinci Resolve.
Really?  ??? Youtube and this forum is full of tutorials and workflow info.

If you're searching for a even quicker way, you can also use MLVFS. It converts on the fly and you don't need so much diskspace and / or you don't have to delete your MLV files.

BTW: thanks for showing a small bug. In MLVApp export settings, "HDR blending" and "Smooth artifacts" should be greyed out, because it has no effect at all when exporting DNG.

Camera-specific discussion / Re: Canon EOS M
« on: October 03, 2019, 10:11:25 AM »
3. It seems that with 10bit I don't get that much dropped frames is this easier on the CPU?
Not to the CPU, but to the card interface.

Another thing that I would improve to be easier for new users (even though the presets are just amazing and makes life so much easier) would be to have a better workflow for converting RAW to ProRess directly.
There will never be a ProRes encoder in this cam. You'll always have to convert it on another machine. Use Switch, MLVProducer or MLVApp. It can't be easier.

Camera-specific discussion / Re: Canon EOS M
« on: September 28, 2019, 06:38:14 PM »
That is all off-topic here, but I'll answer anyway. Better asking such questions in the MLVApp thread!
2. Is there a faster way to convert ML RAW to ProRes 422 LT? MLVApp seems to be taking around 10 minutes for 30 seconds of video.
No. The rendering has to be done no matter which codec is selected. So the time will be the same. Fastest is when not changing an "Edit" area setting.

3. I noticed that it's a very big difference in file size between ProRes 422 & 422 LT with not that much disadvantages.
"Not that much", but there is a difference.

Also it seems that MLVApp doesn't care if you export 4K or 1080p, the export time for a 30 second clip is usually the same.
The rendering has to be done no matter which resolution is selected (original resolution is fastest). So the time will be similar.

Also MLVApp seems to freeze sometimes, a few times I exported 3 minute RAW clip and it just froze after 1.5 hours.
Please post into MLVApp thread, what you've done exactly to get MLVApp frozen. Best, if it is reproduceable.

What about Davinci?
DaVinci has a super-resolution algorithm. Better quality than Lanczos.
But I would only use it with DNG, otherwise you just super-scale your compression artifacts.  ;D

I was wondering if technically there's any quality difference in adding (for example) the Alexa c-log LUT to the mlv app export vs. adding (for example) a flat LUT later in editor?
(Also, the same concept except upscaling in MLV vs. in editor?)
This will probably create banding issues. Always apply Log-C first and then do other processing.
It depends on your editor's interpolation algorithm. MLVApp has some pretty good ones, like Lanczos. I suggest you do that on MLVApp too, as Premiere Pro only has bilinear/bicubic interpolation (which is worse than Lanczos).

Correct. You'll easier get banding in your editor, because your editor has just 8..12bit footage (depends on codec) while MLVApp has the full 16bit working range (you import less, but after WB and other features used bitdepth will get bigger).
Lanczos, Sinc and AVIR should bring better results than bilinear/bicubic which is offered by most editors.

Nope. MLVApp can HQ stretch but not crop. But all NLEs are able to crop.

Pages: [1] 2 3 ... 53