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.

Danne


olofen

Quote from: masc on August 02, 2018, 08:42:27 PM
Yes you can use MLVApp for dual iso. Processing is 20bit (attaching low and high iso).

SUPERGREAT :D
What ISO is best to use? And - is it of equal result to make adjustments in the MLV app as doing it later as exported CinemaDNG uncompressed in Photoshop?
20bit!!! Any other camera on the market that can do this...?
EOS 5D Mark III 1.2.3
Mac OS High Sierra

togg

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

masc

Quote from: togg on August 24, 2018, 04:18:33 AM
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.
5D3.113 | EOSM.202

Danne

 @togg
Could you upload mlv_dump metadata so we can check audio offset numbers? It should be possible to match dng and wav with timecode metadata in post also with dng+wav
mlv_dump -v input.MLV

bouncyball

@togg

I prefer to take a look at the original MLV, please upload it somewhere.

togg

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.

masc

Quote from: togg on August 24, 2018, 08:21:22 PM
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?!  ;D
5D3.113 | EOSM.202

Danne

Longer audio file were problematic with wav embedding in resolve.
Audio offset sync like in mlv app is the best way. How to do this with dng+audio? Probably with time code in wav or dng file. Without a problematic test file hard to do anything.

bouncyball

Quote from: masc on August 25, 2018, 08:13:38 PM
@bouncyball: you remember the little book sync test?!  ;D
Yup :D (I have saved it here for the history)

bouncyball

Quote from: Danne on August 25, 2018, 08:31:16 PM
Audio offset sync like in mlv app is the best way. How to do this with dng+audio?
The sync made by taking in consideration of starting time from the beginning of recording of both 1st video and 1st audio frames. No matter which starts earlier or later, the code calculates positive or negative offset and does sync accordingly, also it aligns the end of the clip and writes needed offset value to the WAV's enhanced header part (needed by resolve) in case, when clip cutting feature is used by MLV App. And this concerns all exports including cDNG + WAV.

I have another idea. Latest crop_rec_4k_mlv_snd branch has experimental audio setting (when mlv_audio.mo is loaded).
ML Menu/Movie/RAW video/Sound recording/Audio delay
Try to set it to 0 (by default it is 1)

regards
bb

Edit: Despite all of these, still, it would be nicer to take a look at the sample MLV.

70MM13

I'm really enjoying working with mlvapp, and getting great results from the tests I'm doing.

Something strange I've found, however...

When I export as 16 bit tiff, I'm getting fewer colours than "save an actual frame" as an 8 bit PNG.

On the order of 110,000 vs 98,000.

I'd expect the opposite!

Looking at the tiff file, it says it's 48 bit, so there's a bit of a mystery here...

masc

@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!
5D3.113 | EOSM.202

bouncyball

Hey guys!

MLV App release v1.0 is out

Look at change log. Masc (alone) w/o our help has done enormous job implementing all of these new features. A bit more than one year passed from the birth of MLV App so we called it Anniversary Relese :D. Enjoy!

And do not forget about feedback/bug report ;) (we are so appreciate it)

best regards
bb

Danne

Awesomeness. Even works on mountain lion. Really good work!

ilia3101

Thank you so much masc and bouncyball!!!!!!!!!!!!
Thanks danne too!!! and everyone else who uses and helkps!!!!

Happy birthday MLV App 💛


Download v1.0, the best version yet

togg

Oh well, congrats! I'll try to come back to those files with a clap showing and audio to test sync in the new version.

70MM13

I use faststone image viewer to count the colours.  Ctrl-shift-T

Yes, the example values I gave are fairly low, but the scene I'm working on is extremely low light!

Congratulations on the new version!  Keep up the amazing work!

I hope you can solve my mystery!

Quote from: masc on August 27, 2018, 04:08:30 PM
@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!

andy kh

Congrats and Happy BirthdayMLVApp. tested on windows 10 64bit. so far so good. keep up the good work
5D Mark III - 70D

bakersdozen

Awesome work and happy birthday! Many Happy returns to come I hope  :)
EOS M + 5D3

GianlucaM83

Happy birthday to mlv app!  :)
A big thanks to everyone for the work you do every day, making magic lantern bigger and bigger and affordable for everyone.

IDA_ML

Happy birthday and congratulations to all developers of this absolutely amazing software !!!

I have a small birthday present for you which you can download from here in the next 7 days:

https://we.tl/t-x0xkLPb2mD

This video (shot on the 100D and the EF-s 18-55/IS STM at 18 fps and 2320x1304 resolution) was entirely processed on MLVApp v. 017.  After correction, the clips were exported into ProRes422LT and the final mount and adding music was accomplished with Filmora.  All this was performed on my 11-year old laptop with Core 2 Duo processor and  4GB of RAM.  I would have never thought that such a massive video processing work could have been accomplished on such a weak laptop.  And guess what - all processing went pretty smoothly.  I imported all clips into MLVApp, applied the corrections to one clip and copied them to the other ones, did some fine tuning on every one of them, started the export and went to bed.  In the morning, when I woke up, all files were ready, waiting for me.   And since ProRes is an editable format, all clips played well in Filmora too.  I decided to scale the final video down to FHD to keep the file size reasonably small.  Sorry to those with high-res monitors.

Thank you so much, guys and keep up this excellent work!

Sincerely yours,
IDA_ML.

masc

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.
5D3.113 | EOSM.202

70MM13

It makes sense...  I can't see any degradation on the 16 bit tiff, so perhaps faststone is just incorrect.

Maybe there's another way to get a clearer answer...  Perhaps gimp has a similar colour count function.

PS: gimp has a colour count function, and according to it, everything is fine!

Test image was approximately 94,000 colours in the 8 bit PNG export, and 101,000 in 16 bit tiff.

In case anyone is interested in the function, it's under colours/info/colourcube analysis

Thanks for the help!

12georgiadis

@masc : incredible update ! you seem to have read my #114 post on fast cinemadng forum about the MLV conformation. I'm currently testing it with proxys from MLV app. For now, MLVs are detected and well imported from an FCPXML with ProRes proxy edit in MLV app !
Later, I'll try to export these Mlv into APR444 and conform on Resolve with the same Fcpxml, to see if it replaces ProRes proxy with 444 and keep the edit correctly

edit : working with mlv from eosm
1) exported proxy from mlv app
2)imported in fcpx
3) exported fcpxml
4)importe in mlv app and use fpcxml assistant, pointing to mlv = OK
5) exported pre-corrected MLV to ProRes 444 = ok
6) import fcpxml resolve = ok to point to prores 444 keeping the editing

fail : form this timeline, export to fcpxml and reimport to mlv app = not working

what version s of fcpxml are compatible in mlv app ?

Thanks,