Things to do next!

[ilia3101]

I'm in a mood to get back to MLV App again. Getting another 5D2.

What should be next big thing? Other than fixing and merging BetterProcessing...

Also did anyone here use and value caching at all? Worth putting effort in to fix it?

I'm thinking caching should work like this: cache frames only when they have been visited in the timeline, to not have 100 percent CPU all the time.

[masc4ii]

I like your mood this way 😄

Next big things... hm... when going through our Issue List:

• Most important and maybe interesting for v2.0: finish better processing branch
• AutoWB
• Corrupt frame detection / replacement
• Bad pixel selector / load / save
• Caching... yes (while I don't really miss it, but I am not alone here)
• Multiple receipt slots (this is more a graphic/interaction design question than an implementing problem)
• Acceleration for DualISO
• Timelapse export modes (with interpolation, etc.)
• LMMSE bugfix
• ...

[ilia3101]

crazy idea, but it's exciting to me. Could we write the MAPP files as a block at the end of MLVs? I know maybe we should not be touching original files, but I think if we just add it on to the end it's quite neutral, and as far as I know it should not bother other apps like mlv dump mlv producer etc, as they should just skip the block they do not understand.

A MAPP block would be layed out:

typedef struct {
    uint8_t     blockType[4];    /* "MMAP" */
    uint32_t    blockSize;    /* total block size */
    
   /* just the MAPP file data (whatever the size is) */

    uint32_t    blockSize_end;    /* total block size */
    uint8_t     blockType_end[4];    /* "MMAP" */
}  mlv_mapp_hdr_t;

And when opening an MLV file, first of all go straight to the end, check for "MAPP" string, and if it is there, check the size right before it and read the MAPP file.

And this would reduce "junk files" as masc says. And would speed everything up in an invisible way. @bouncyball-git what do you think?

[bouncyball-git]

And this would reduce "junk files" as masc says. And would speed everything up in an invisible way.

Well... it will, however the the current .MAPP file includes whole audio (correctly cut and synced) and this will result in duplicate data. Also MAPP has variable size because of audio and all offsets to video frames.

[ilia3101]

The variable size isn't necessarily much of a problem, but you are right audio makes it wasteful (I still think it would be quite nice to do though, if audio could be disabled).

[masc4ii]

On the other side... the MAPP system works not bad atm - me too, I really use it as it is now! And if I don't like the MAPPs, I still can delete them. If you change the original file, going back will be a problem. If something fails, your file might be damaged forever.

[ilia3101]

well at worst you get a half written block at the end in this case (I think), but it may cause problems like "invalid block size" or whatevre

[iFloris]

Hello @ilia3101 great plans as always! I have a suggestion that you might be willing to consider: Writing the original date and time inside an export. I ran into an issue with this where I went back and re-exported some older mlv files with better settings, but I had a really difficult time getting the video synced up with the external audio because the times and dates were completely different. This was from a scripted shot with more than 12 takes, so in each take both video and audio were quite similar and of course this was not shot with a clapboard :( if there was an option to export with the original mlv time and date, this would have been a breeze. I realise that this might be an edge case. What do you think?

[ilia3101]

you mean write it in to the image as visible text?

[iFloris]

@ilia3101 no, sorry for being unclear. I meant the file date so that the original MLV and the exported (mov) have the same creation date. I hope that this might be somewhat easy to implement :)

[ilia3101]

Oh ok. There's two ways I can imagine this can be done, don't know which one is right.

Set some kind of metadata inside the MOV file (like exif)?

Or set the creation date in the file system? I think most file systems don't have creation date feature, only last modified, so I don't think most software looks at it.

[iFloris]

Oh I am under the impression that the date/time created is one of the most basic file system functions, next to date modified. Am I mistaken? Or perhaps I have not explained what I intended the creation time/date for well enough.

What I usually do when matching video and separately recorded audio is sort by date/time created and then sync. I used to use pluraleyes, but lately FCPX has a good-enough function for it as well. So if MLV-App writes the MOV with the same creation time/date as the source MLV it would be in sync with the external audio.

I think you can get file created and modified time/date using C# using FileInfo class:

FileInfo fi = new FileInfo("path");
var created = fi.CreationTime;
var lastmodified = fi.LastWriteTime;

The fi.CreationTime of a MLV file in this case could perhaps be used to set the new mov file CreationTime.

Does that help clarify what I mean?

[woefi]

set the creation date in the file system?

Today I converted a bunch of my MLVs to lossless cDNGs (for DaVinci) to save some space on my harddrives. I too noticed, that the file system dates (modification, creation) were all set to "now" (compared to mlvfs, which sets it to the original recording time)

Additionally, when looking into the EXIF data, each frame (.dng) has the same timestamp as the last frame of the shot.

Although I don't know an specific example of where this screws things up, I would have more peace of mind if this was implemented so I can do my conversions and delete my original MLVs, knowing ALL metadata is brought over.