Messages

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.

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

Picker is no problem... functionality is there, we just need another icon -> easy exercise. But we need some buttons for adding/deleting pixels, for loading/saving a pixelmap. We should think about another widget. 

Cool! I'm gonna open the new issue on github then

Actually used imagej for getting coordinates into a pixel list:
... Code from raw2dng if I don´t fail to remember).

Yeah! That's right

So please ad an manual bad pixel fixer cuz I only have one hot pixel on high iso on the my 5DIII.

I always wanted to have that feature myself. Pick point(s) in the frame by mouse cursor and save it as custom map to use it right away (with current MLV) or with any other clip recorded with the same camera (should be doable after relative adaptation to raw buffer resolution).

This must be implemented on raw correction level to be useful with DNG export as well. I'm gonna think about it...

Edit: @Danne has implemented something like this for switch some while back. He is using some proggie for pixel selection... don't remember the name.

Well right now I am looking for a user friendly way to find my camera serial number. 

Well serial info could be useful if several same model cameras are used on shoot.

@Kharak

What you exactly need. Details please we can not dump all mlv structure here, as you know there is a dedicated tool called mlv_dump for this.

Or at least can someone recommend simple app that could pack a bunch of dng files into mlv?

Nope, there is none (theoretically this could be done but nobdy did it yet, except some g3gg0's experimental code in ML main repo)

We decided that MLVApp's not gonna support DNG input natively. Use MLV output for silent pics (record MLV raw video) and do not delete converted MLVs.

Hmm...

Hey Danne I think you will be interested in deep_demosaick to use it in Switch

... Have a look: (left=boxblur, right=RBF)

Edit: playing around with RBF parameters can minimize those artifacts.

This is amazing!

Soon we will release new SDK with less requirements for GPU memory, so any NVIDIA GPU will be fine.

Cool.

... There are no restrictions for the player.

Except it absolutely requires powerful NVIDIA(only) card and... there is no long awaited Linux version yet.

Bad (dead/hot) pixels should always come from your sensor (or do I missunderstand?!).

It is truth.

For MLVs taken from bad flash card the image artifacts will be far more severe. Could even be fatal for this particular MLV .

this also reminds me to ask does this have anything to do with shooting in Lossless 12-bit while we're at it?
.....
Again after each crash I just simply erase the last corrupted file and redo which then spits out OK.

Well, as you understand it is hard to understand the exact reason because of the random nature of the issue you are experiencing. Unfortunately I can not reproduce it .

Could be 12bit lossless as well. Sometimes this kind of footage is a bit tricky to handle due to lower white level and ugly scaling requirement for proper dual iso processing.

There is no reason to enable bad pixel fix almost ever, especially if it's dual ISO. No one has noticed my red pixel yet.

Right... Except for some cameras like I had in the past (60D) with maybe 50 bad/hot pixels in every frame.

@masc: let's change it to off by default.

Using debugger the app exports in slow-motion and does not crash. LOL. As usual.

Yup

Open all chunks also called when darkframe mlv is loaded (no need for DF but that's how the basic MLV loading function works, which is reused there) so maybe there is hiding something...

@bouncyball: also tried using darkframe and also got a crash on first try.

Yeah... something is wrong and it's wrong from the beginning. I have to try to nail this with valgrind.

Ah, OK, thanx .

1. 1.5 version crashes constantly after processing 502-504 frames on any file (longer than 504 frames).
If process without black frame it not crashes.

Very odd problem indeed. I have to reproduce this somehow...

Edit: which OS?

I guess @masc should answer that MASK question

+1
Should even be independent even if working on the same clip

Haha flickering would happen only if we will implement processing of EVEN and ODD frames in mlvapp. Then one instance of mlvapp should process the odd frames with different settings than second instance even frames

Now we´re talkin´

Yes, and one more thing, the real single frame corruption can be detected only when decoding wrong lossless raw data by LJ decoder (it spits error that data can not be decompressed). If raw is uncompressed we can not detect corruption until we look at the image on the screen

Hello everyone!

Is the problems happens due to mlv_dump code it should be possible to insert the "relaxed" mode skipping files right bouncyball?

The mlvapp import has nothing in common with mlv_dump code at all

Let me make clear some "corrupted frame" aspects here.
1. mlvapp importer reads bytes from MLV but on that stage does not analyze any frame data itself for corruption.
2. errors come from the fact that _MLV_ itself is corrupted, e.g. specs are violated, header block missing or block size is not matched to the value written in the header etc etc ...
3. error is passed to higher (QT) part of the application, where the proggie (on error) spits out the message box with error and where some actions could be performed (skip, cancel etc).
So it is all about MLV corruption, not the particular frame, hence substitution with black frames is not applicable.

BTW mlvapp has built in brute force method (I've implemented long time ago) if the block header could not be found on common/expected address offset, proggie searches the block name until the end of file. I have one corrupted MLV like this and mlvapp loads it fine, slower though.

Now what can we do: introduce somewhere checking option allowing, on error, stop processing of current MLV (leave all files produced intact) and proceed to the next one without user intervnention. This will finish whole batch despite corrupted MLVs.

The problem aborting at corrupted frames was discussed many times here already. Mostly a corrupted file can't be handled for roundtrips, audio does not fit to video, linking does not work, etc. ... these are only some of the reasons why bouncyball and I decided to aborted export for corrupted clips. If just the last frame is currupted, this might be a a special case - but even than it leads very often to linking issues when working with Resolve or FCPX.

I guess only problem here will be with linking as masc described above. But if one let the option (I described above) checked, he/she already agreed that this could happen.

Regards
bb

Code Select Expand

QT_SCALE_FACTOR=2 ./mlvapp

Huh! I loved it! Makes it look like on retina display (which is actually IS 2x2 real pix -> 1 gui pix), very crisp!

Yup, give us assets to chew on