Messages

I added the new factors to the repository on github. I don't know if autodetection works - I have no test clips. Please upload some short clips (some frames are enough) and/or test! Thx!

Can you please add the following values for stretching the height:
0.33 (0.333 more accurate value) for 1x3 Binning and 3.00 for 3x1 Binning. Or maybe making these stretching values changeable with a double click?

Sure, that should be possible. Is there a way to read out the ratio from the MLV yet? For 5x3 it was possible and we could set it automatically. What sould be the expected values, if they are set? 3 and 1, 1 and 3?
Here our auto detection code:

Code Select Expand

/* Get image aspect ratio according to RAWC block info, calculating from binnin + skipping values.
   Returns aspect ratio or 0 in case if RAWC block is not present in MLV file */
float getMlvAspectRatio(mlvObject_t * video)
{
    if(video->RAWC.blockType[0])
    {
        int sampling_x = video->RAWC.binning_x + video->RAWC.skipping_x;
        int sampling_y = video->RAWC.binning_y + video->RAWC.skipping_y;

        if( sampling_x == 0 ) return 0;
        return ( (float)sampling_y / (float)sampling_x );
    }
    return 0;
}
Edit: I need some sample MLV for testing - 1 or 2 frames with each possible factor are enough.

Have you tried one of the "still supported" tools, e.g. MLVFS, MLV-Producer, MLVApp,...? Do you talk about one single MLV file, or .MLV+.M00+.M01+...?

I saw it recently also be used in MLV APP, but that version was compiled by somebody on this forum, under development, not sure if it has already LMMSE debayering option in the current build ?

Yes, it is included in MLVApp v1.0.

Could you add "Zoom fit" and "Zoom 100%" as symbols to the gui, please? I did a quick collage with GIMP, so you can see, what I mean:
https://seescho.files.wordpress.com/2018/09/mlv.jpg

That would just be drag&drop in QtCreater for these 2 actions. But would you really use that at this position? Isn't the rightclick menu better (jumps to the position where you clicked when zooming in) or typing "F"?

@70MM13: jp2000 export in mov container is added to MLVApp. You can compile it or wait for next release. You can then choose between the options .jp2 sequence and .mov when codec JPG2000 is selected.

@reddeercity: sad to read that. I enjoyed every day reading your messages, what you found out. You are so close now - the goal should not be far!

[Edit]

I just read that BMD gave out source and all for their new Black Magic Raw codec and is available to developers.

Link: https://www.4kshooters.net/2018/09/14/ibc-2018-blackmagic-design-introduces-a-brand-new-blackmagic-raw-codec/

Do you think it is possible to implement it in your already more than awesome MLV APP?

Thanks for posting. I'll study the sdk, then I'll know, if it will be possible

Edit: The SDK is decoder only. So unfortunately there is no way to support it as encoder.

MLV App causing this scan lines in the Sun when processing Dual ISO files. Any way to avoid it?

Filming directly into the sun often causes problems, also without dual iso (brings a black dot in the middle of the sun). I think the only way is to avoid to film into the sun, or tracking the sun in post and attaching e.g. a bright circle on it (possible using Resolve).

It would be fantastic if MLV app had an option that combines the movie clips together when converting so it will be one whole file not many seperated.

Why not using a NLE? For MLVApp this would only work if all clips had the same resolution - to check all this would make it complicated and would also limit the resulting functionality.

There has to be a better way than color correcting in the mlv app? What's the point shooting in raw when you have to color grade prores in davinchi or basic grade raw in the mlv app?
Okay you have the ability to get a prores file from your dslr wich normally isn't possible but then again you could also use a external recorder to record in prores.

It's not impossible this way but really inconvenient watching compressed footage and manually stretching them, someone has to have the ultimate workflow for this right?

Sry... I don't get what you are writing about. First you had the problem that Premiere is not able to read the stretching metadata in cdng. Now you want to grade prores files in Resolve (Resolve is able to read stretching metadata in cdng)... ?!?!?! And please define "better" in terms of color correcting. MLVApp should already be better than Premiere (not ACR) in this area, Resolve is much better but works fine with cdng. When using premiere you could correct and grade in MLVApp and cut the prores files in Premiere. Or you just use proxies made by MLVApp, cut it in Premiere and grade the cdng in Resolve, or ... or ... or ...

No matter how many bits I want, ffmpeg gives 8bit. Here what we could get (5D2 example):

Code Select Expand

General
Complete name                            : /Users/masc/Desktop/M15-1953.mov
Format                                   : MPEG-4
Format profile                           : QuickTime
Codec ID                                 : qt   0000.02 (qt  )
File size                                : 6.18 MiB
Duration                                 : 342 ms
Overall bit rate mode                    : Variable
Overall bit rate                         : 152 Mb/s
Writing application                      : Lavf57.71.100

Video
ID                                       : 1
Format                                   : JPEG 2000
Format profile                           : No restrictions
Codec ID                                 : mjp2
Duration                                 : 320 ms
Bit rate mode                            : Variable
Bit rate                                 : 160 Mb/s
Width                                    : 1 856 pixels
Height                                   : 1 044 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 25.000 FPS
Chroma subsampling                       : 4:4:4
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 3.310
Stream size                              : 6.12 MiB (99%)
Language                                 : English

Thanks @70MM13. You mean having multiple "slots" for receipts, than just one (as it is now)? That is no bad idea and should work somehow. I'll think about how to integrate that.
JPEG2000 as mov... hm... now I got only as sequence, right?! MotionJPEG is also something different?! (Don't know exactly these codecs, sry.) If ffmpeg can do that (maybe you found a call somewhere?), MLVApp could do that in future too!

Edit: found somewhere

Code Select Expand

ffmpeg -y -t 1 -i OUT2.mov -vcodec j2k -pix_fmt yuv422p -an -strict experimental testj2k.mov ... I'll try that out one day...

Now I know Mlv APP does stretch them in some way, only that some programs don't recognise the data included to a raw sequence and that Premiere Pro doesn't. Lightroom and After Effects seem to automatically read the data and stretches the footage to 1920 x 816.

Is there another, faster and more ergonomic way to do this is my question? Stretching the height of the footage before editing in premiere pro?

This happens only if you are using cDNG. You could also color correct in MLVApp and export in ProRes or another format. Or you stretch manually in Premiere, what means 100% the same, because stretching in cDNG is just metadata, no "real" stretching inside the cDNG.

@masc, @danne, is there a function that cut black frame on h264 + reset tc to zero to sync it with MLV ?

No, importing h264 is not supported at all. I don't know if Danne is able to write a scipt for that...

Ok for amaze but do you think lmmse or igv can help to reduce aliasing ?

No. I have sometimes some colored artifacts in trees - these are a bit less with IGV... but therefor on clean surfaces you'll find a kind of structures.

Compiling instructions can be found here: https://github.com/ilia3101/MLV-App
You are on Windows? You just need a Qt5.6 or newer installation with MinGW, then download sources from github and follow the instructions. If you are on OSX, try Dannes compiler app, which leads you through...

Mostly AMaZE is the best demosaic algorithm. For some clips IGV or LMMSE may look a little better, specially if AMaZE brings some false color artifacts.

MLVApp still runs 100% on CPU, that is why it runs on nearly every computer from the last 10 years or older, no matter which OS (Win/Linux/OSX), what CPU or what GPU (if there is any at all). Since the last version we support much better multithreading, what made rendering up to double speed to before.

@12georgiadis: you can compile it? It is just commited to the repos. Cool, would be nice to know if it works fine with 5D3 proxys!
Hehe, yes, I went crazy with my own little projects: ~500 MLVs and only 50-100 of them were used in a project and have to be corrected/graded. Selecting these files manually was very time consuming and borring.

@12georgiadis
Yes I read that, but it was implemented before... nice to hear it mostly works. I can't tell you what version of fcpxml is compatible - I have no spec and reverse engineered. I think your problem is, that Resolve renames the clips. Somewhere in the settings you can setup the clip names to real names. Maybe check this and it should work again. All MLVApps assistant needs is a coorect clip name. In the fcpxml I just search for e.g.

Code Select Expand

<clip name="M04-1441"so I know I have to search for M04_1441.MLV in the folder you set in the assistant. If Resolve builds clip names of e.g. M04-1441_0000001-0000054 my assistant is lost atm.

Edit: I see, Resolve is exactly doing what I expected plus I found another small bug. Will do a fix for all that...
Edit2: Done. All versions of fcpxml from Resolve opened fine now.

Happy first birthday MLVApp and thank you all for your nice words and support! I hope you like all the new features and I hope they work for you too.

@IDA_ML: nice! And I use it nearly the same - mostly on a very old laptop. With v1.0 performance is improved, so it should work even better - on old and newer systems.

@70MM13: hm, I tried it my self and these numbers are strange. I get only slightly higher number of colours for 16bit than for 8bit for my test clip. BUT: I rendered another 16bit TIFF with Photoshop (looked nearly the same then) and it had even less colours... I am not sure if these numbers are correct.
Another test with FastStone Viewer: 14bit CR2 had 76k colours, same picture as 8bit jpg had 82k.

@70mm13: very interesting. How do you count the colours? The frames are exported in very different ways:
- 8bit: internally convert 16 to 8 bits, use Qt library to save 8bit PNG
- 16bit: directly stream the (processed) rawdata (internally 16bit) to ffmpeg which saves the 16bit TIFF
So if your values are right, there should be a problem with ffmpeg (or our ffmpeg call).
BTW: only 100.000 colours? (3x)8bit has already 16.000.000!

Mmm ok if you're not seeing that I'll try to upload a MLV, thanks. It will take some time tough I've switched to other hard drive at the moment.

@togg: I remember, nearly a year ago I recorded a sync test when we started implementing audio. I had one clip where audio was 1fps earlier than video. But: that means when syncing it correctly, there is no audio for the first frame - or we would have to cut away the first frame. There is only a very little more audio than video in a MLV. We decided to sync it by using the timecode (therefor we had to cut a very very little in front and in the rear of the audio channel, if I remember right, or only in the rear?!). Nobody really knows, on which position the audio is more correct than using the timecode... here a screenshot from my clip, it is the same with yours?

@bouncyball: you remember the little book sync test?! 

Am I the only one who is seeing an offset in the audio sync exports with dng? It is like minus 1.5 frames.

I don't know your files, but audio channel is always synced by timecode to video channel in MLVApp. Sample MLV would be nice.

File Export:
CinemaDNG Uncompressed

CDNG is RAW, so no processing is done at all! Only RAW Correction changes the output for CDNG.

Ha! Told you it was malloc()
If you need to test some patch, I will be here.

Hehe... thanks! But what can we do, if a standard function like malloc works not as expected... and on one single OS only?!

2- Processed with MLVApp (no sharpness or denoise filter) and exported to DNxHR HQ 8bit. This file was used as the reference file.
3- Interpolated the reference file to 3840x2160px on Premiere Pro v12.0.0 (with "Use Maximum Render Quality" box enabled) and exported to DNxHR HQ 8bit. I didn't wanted to use some better interpolation algorithm, like NNEDI3 or SuperResolution-based. Most people just use Premiere or FinalCut to do this.
4- Uploaded both and waited for youtube conversion.

But this way you upscale also the artefacts coming from conversion in point 2?! I think this way the upscaled version can't be better (until this step). What happens if you resize in MLV App? Maybe the resize algorithm from ffmpeg is not as good as the one from Premiere, but you don't upscale compression artifacts.

@masc

IMHO stretching should be restricted for any, non ffmpeg, exports in the gui.

But this would mean we disable nearly the whole GUI if MLV or CDNG is chosen in export menu... I am not sure if I like this idea...

With this darkframe crash some light comes in the dark for me... on Windows only, memory allocation does not work as expected. See issue #96 on our github repos.