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

[masc]

Exporting a MLV is no problem, but importing a non-MLV file into MLVApp is. Someone "just" has to write the lower level modules new from scratch.
Until this is done, I recommend Ilia's hot tip from first post:

...

• If you want to process DNGs, use DNGApp.com
   

...

[Jip-Hop]

Thanks! That's what I expected. Will have to be sure before I delete my MLV files for now then. Does DNGApp still exist? The link doesn't work for me: http://DNGApp.com.

[masc]

Does DNGApp still exist? The link doesn't work for me: http://DNGApp.com.

This was the joke...

Will have to be sure before I delete my MLV files for now then.

This is indeed the best option.

[Jip-Hop]

This was the joke...

You got me there!

[Jip-Hop]

I'm unable to export my MLV file to CinemaDNG Lossless with Chroma Smooth 3x enabled.
I get the following error: "Could not save: some dng frame number. How would you like to proceed? Skip Frame. Abort current export. Abort batch export."
Some frames get exported fine, even some MLV files from todays recording processed fully.
But most of them fail.

When I disable Chroma Smooth 3x I can export without any issues.

I've got Fix Focus Dots enabled, but would like to enable chroma smooth as well because it cleans some of the aliasing.

Heres the link to an example MLV file: https://www.dropbox.com/s/3mfepggxbw473bd/M01-0912%20short.MLV?dl=0.

I'm on macOS Mojave with the latest MLV App version 1.7 and freshly downloaded focus dots maps.

[masc]

Thanks for reporting. The description was good, I could reproduce immediately with your file. I run the program with my debugger and now I see, that this error message is produced by the lj92 library. This library compresses the data.
This is the function which returns with the error code:

Code: [Select]

int lj92_encode(...)
    ...
    // Scan through data to gather frequencies of ssss prefixes
    ret = frequencyScan(self);
    if (ret != LJ92_ERROR_NONE) {
        free(self->encoded);
        free(self);
        return ret;
    }
I don't know what exactly this function does... there is nearly no comment inside. @bouncyball: do you have any idea?

For now you could just export your clip uncompressed.

[Jip-Hop]

Thanks! Glad to hear the report was useful. I can confirm on my end that exporting uncompressed works in this case. So I'll do that instead. Hope it gets fixed in the future because I like RAW but I also like to save space ˆˆ

[theBilalFakhouri]

Is it the right time to get rename option in MLVApp session for MLVs ? And export it with the new given name for each MLV , this is gonna be life & time saver!

[domo94]

Is there a way we can set up and automated import feature where it applies a specific setting to your footage immediately upon import?

I usually just throw on Cineon Log, fix hot pixels / bad pixels, and change debayering.
Then export in 4444 or 422 depending on the project.

It would be nice to just import, and preset, then export.
Would make my life 10x easier.

Also, this app crashes at times when loading or viewing footage.

MLV 14 bit RAW is hefty. I don't think 1.5 crashed as much.

[Danne]

You can build your own preset. Check the tabs for export receipt.

[domo94]

@Danne
I'm not sure it works the way I would personally like it to.

I'm talking about upon import, the settings are applied.
What I do is set up 1 clip, fix pixels, find LOG, then copy, paste onto all the clips.

It can be a little slow and choppy because of the MLV App performance.

[Danne]

Only slowdown is indexing. That's how the formats was designed. Other than that I don't see any different importing a receipt from what you just wrote...

[Danne]

On a sidenote. How is mlrawviewer indexing frames. It's blazing fast even on an old macbook air...

[domo94]

Importing a receipt isn't automatic, though.

I'm not familiar with this function and it's asking me to open a .marxml file.
Would I have to do this EVERY TIME I upload files?

Idk, my program tends to crash.
White balance selection is terribly slow.
Import takes time, that's a given considering the huge file sizes. I get a 'not responding' prompt every time I import MLV files.

Is the indexing happening WHEN I IMPORT MLVs?

[Danne]

Yes, and if you create mapp files for all mlv files it will be indexed and ready next time you open. But they need to be indexed at least once to create mapp file so put it over night if having huge files.

Well exporting/importing a recipe file is not that hard. There's also a short cut section of your latest project worked upon.

@bouncyball
These indexing files. Why are they needed? Or could they be created like dummies? Isn't there enough info in header/footer to just build indexing without chewing each and every frame? Amount of frames are there in header metadata already right? Maybe that is what mlrawviewer does since dng amounts sometimes varies...

[masc]

Is there a way we can set up and automated import feature where it applies a specific setting to your footage immediately upon import?

No.

I usually just throw on Cineon Log, fix hot pixels / bad pixels, and change debayering.
Then export in 4444 or 422 depending on the project.

You can set it once, copy, select all, paste.

It would be nice to just import, and preset, then export.
Would make my life 10x easier.

Don't agree.

Also, this app crashes at times when loading or viewing footage.
MLV 14 bit RAW is hefty. I don't think 1.5 crashed as much.

Really? Please try to figure out how you get it crashed. I played a lot in the last week with 450GB, 500 MLV files 14bit uncompressed and/or lossless - without any crash.

What I do is set up 1 clip, fix pixels, find LOG, then copy, paste onto all the clips.

It can be a little slow and choppy because of the MLV App performance.

What are you doing? Pasting on 500 clips is done in under a second on a 9 years old laptop.

Importing a receipt isn't automatic, though.

Correct. It is 3 mouse clicks.

I'm not familiar with this function and it's asking me to open a .marxml file.

Right. It is the .marxml you exported once a lifetime before.

Would I have to do this EVERY TIME I upload files?

You have to do it once for a session before you export.

Idk, my program tends to crash.

Please try to reproduce and tell us how you get it crashed.

White balance selection is terribly slow.

0.5 sec on a 9 years old laptop, yes. Until now we don't have a better solution. Waiting for help since a long time here...

Is the indexing happening WHEN I IMPORT MLVs?

Indexing happens when loading a file from the session into the viewer, if "Create MAPP" is enabled and no MAPP is available.

[Jip-Hop]

I was crashing MLV App yesterday a lot when trying to export MLVs which stopped recording due to card full. Had to ignore the last portion (maybe 60 frames, don't remember exactly). Apart from that seems to be quite stable for me.

One thing which is a bit inconvenient though is that sometimes MLV App will halt batch export if it can't process a certain frame. It will give you three choices (skip the frame, cancel the batch export and another one).

Would be great if there's an option to just continue always, and warn about issues afterwards. Like when copying in Windows where it will ask you to overwrite each individual file, or with one click overwrite all. Or somehow put these problematic ones at the end of the queue. So that I can answer all the pop-ups, which halt export, at once. Otherwise I have to monitor the export constantly and can't leave the computer.

Still a really hot app though!

[Danne]

Indexing happens when loading a file from the session into the viewer, if "Create MAPP" is enabled and no MAPP is available.

So there´s three options here?
1 - Import MLV files without Create MAPP enabled? How is it disabled?
2 - Create MAPP enabled? Or do you mean it´s enabled when pushing this option?
3 - Push Create MAPP or push Create All Mapp Files Now?

Importing a big MLV file will take longer than a short MLV file so I´m curious what is indexed upon import if MAPP file options isn´t selected? Is it waiting for the last frame to get indexed? In this case it would be useful to have an option to fast import by reading header data instead. Reworking these routines will have a significant speed increase in workflow.

[domo94]

@Masc
OH!
I understand. It's a global paste, so to speak, that would apply to all footage. Oh that's kind of nice, works fine. 3 mouse clicks is just fine.

As for the crashing, I'm not sure, I'll try to reproduce some stuff.

Usually I get mega slow-downs when I import footage and then when I double click on a shot in order to preview, the longer the shot is, the longer it takes to load.

Actually, I realized where I'm confusing everybody. The IMPORT is quick, my mistake. The action to drag, drop, and then letting MLV App import the footage unto the queue is a .5 second process.
I guess I am generalizing it together with the computer's ability to actually playback and load a clip in the view monitor.

I am understanding this better now.

[masc]

I was crashing MLV App yesterday a lot when trying to export MLVs which stopped recording due to card full. Had to ignore the last portion (maybe 60 frames, don't remember exactly). Apart from that seems to be quite stable for me.

Could you please upload this file(s) / clip? We would need such files for debugging.

One thing which is a bit inconvenient though is that sometimes MLV App will halt batch export if it can't process a certain frame. It will give you three choices (skip the frame, cancel the batch export and another one).

Would be great if there's an option to just continue always, and warn about issues afterwards. Like when copying in Windows where it will ask you to overwrite each individual file, or with one click overwrite all. Or somehow put these problematic ones at the end of the queue. So that I can answer all the pop-ups, which halt export, at once. Otherwise I have to monitor the export constantly and can't leave the computer.

Ok, thanks. We can think about that.

@Danne:
- if a MAPP is available, it is always used. The clip is imported qucikly.
- if no MAPP is available and "Create MAPP" is disabled, the clip is imported without indexing and with full read out. This can take some time in dependency to the size of the clip.
- if no MAPP is available and "Create MAPP" is enabled, indexing is done with full read out. This can take some time in dependency to the size of the clip.

MAPP files consist of the following packages:
file
rawi
rawc
idnt
expo
lens
elns
rtci
wbal
styl
wavi
diso
dark

Usually I get mega slow-downs when I import footage and then when I double click on a shot in order to preview, the longer the shot is, the longer it takes to load.

This just happens, if no MAPP is available (hopefully).

[bouncyball]

Hi guys!

@Danne

These indexing files. Why are they needed? Or could they be created like dummies? Isn't there enough info in header/footer to just build indexing without chewing each and every frame? Amount of frames are there in header metadata already right? Maybe that is what mlrawviewer does since dng amounts sometimes varies...

I'll try to shortly explain what indexing is:

It is done not just for counting frames.

1. For speeding up reading MLV we _MUST_ find and save into index file (MAPP, MRX, IDX, etc) the physical offsets to the raw data for every video frame in current MLV. Knowing exact offset to the raw data needed (during plaing or moving frame slider) we can access it in the file _instantly_ w/o searching VIDF header over and over again. Example: if needed frame No 507, we get by function offset_to(507) and read frame size amount of bytes into the buffer. Basta

2. Sometimes frames are written in MLV file with wrong order. Example: 1,2,5,3,4,7,8,6,10,9. So they must be ordered correctly according to their timestamp. Before recording the index to MAPP they are sorted with ascending order.

If we are not saving MAPP at all, the indexing is still done in memoy for every MLV over and over again (if mlv is big enough, this takes lot of time). It is just very convenient to save all gathered data to file for getting lately with just one burst read and put to memory. That is what saves a lot of time on slower HDDs and even on SSDs for big files.

One more thing, the frame amount read from MLV header sometimes differ from actual number. So calculating frames according to this value is inaccurate and unreliable.

br,
bb

[bouncyball]

And I think indexing in mlrawviewer is done in the background in a separate thread. File is playing with some hickups though, before indexing is fully done.

[ZEEK]

@Ilia3101
Hey, I was wondering if the codec option "10 Bit Uncompressed" could be re-incorporated into MLV App? I used to use this export codec back in the days with the Canon 6D ML RAW. It was very fine indeed! I downloaded the old MLV Apps to see if I could find it again, however it's not there! Thanks in advance.

[masc]

@Ilia3101
Hey, I was wondering if the codec option "10 Bit Uncompressed" could be re-incorporated into MLV App? I used to use this export codec back in the days with the Canon 6D ML RAW. It was very fine indeed! I downloaded the old MLV Apps to see if I could find it again, however it's not there! Thanks in advance.

What codec format is that? And which version had it (any idea)? There shouldn't be lost any codec...

Edit: what about "Uncompressed AVI -> V210 10bit"?

[ZEEK]

What codec format is that? And which version had it (any idea)? There shouldn't be lost any codec...

Edit: what about "Uncompressed AVI -> V210 10bit"?

It just said 'Uncompressed 10 Bit' as an option towards to bottom of the list from memory. It wasn't Uncompressed AVI. I may have to look back and look at the earliest ones of MLV App. I definitely remember it being there back in the day.