Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Things to do next! #172

Open
ilia3101 opened this issue Jul 22, 2019 · 12 comments
Open

Things to do next! #172

ilia3101 opened this issue Jul 22, 2019 · 12 comments
Labels

Comments

@ilia3101
Copy link
Owner

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
Copy link
Collaborator

masc4ii commented Jul 23, 2019

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
Copy link
Owner Author

ilia3101 commented Jul 25, 2019

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
Copy link
Collaborator

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
Copy link
Owner Author

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
Copy link
Collaborator

masc4ii commented Jul 26, 2019

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
Copy link
Owner Author

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

@masc4ii masc4ii added the Info label Sep 9, 2019
@iFloris
Copy link

iFloris commented Oct 10, 2019

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
Copy link
Owner Author

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

@iFloris
Copy link

iFloris commented Oct 11, 2019

@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
Copy link
Owner Author

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
Copy link

iFloris commented Oct 12, 2019

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
Copy link

woefi commented Oct 8, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants