Fast MLV import - Githubissues

masc4ii commented 6 years ago

@bouncyball-git starting implementing a fast MLV scan where just the first frame is loaded for preview. A first proof of concept shows that import is way faster with that. Unfortunately we don't get the frameCount and my loading concept does not work without. I don't see a chance to get the frameCount of the MLV when we want to be so fast. So the only way is to reimplement the whole file loading in the Qt part. What we do now:

load file to lib
load frameCount and set cutOut with that number
reset receipt (with frameCount) to default, or load receipt settings
load preview (preview picture looks processed if there is a receipt)
load this settings to GUI, what limits all values to a valid range
do the same with eventually next file

New concept:

load just first frame with check if file is readable (preview mode)
load receipt if there is one, or reset with frameCount to max of uint64_t
load same receipt to a temp receipt, load this to the processing part (values are not limited) OR load same receipt to a temp receipt, load this to the GUI (values are limited), don't save settings to actual receipt before loading next (for not crushing cutOut)
load preview (preview picture looks processed if there is a receipt)
do the same with eventually next file
load last file to lib and GUI
for the selected "current" file the values are limited to the valid range (same in export)
when just importing and then exporting (without further interaction) the program must parse frameCounts to be able to calculate ETA

I hope I have not forgotten a fact... :-S

masc4ii commented 6 years ago

Maybe we should release a v0.12 before, because this change is huge...

bouncyball-git commented 6 years ago

OK, we can make release 0.12 with commit 8e9ab59dc08.

bouncyball-git commented 6 years ago

Would it be possible to commit the changes of the fast preview in the library modules? In the MainWindow please let the old version (or setting the new preview variable always "false"). I would like to play a bit around...

I don't want to merge it to the main repo yet because of the very experimental state.

Are there many changes in Ilias code?

Yes, quite of changes in mlv importing part.

bouncyball-git commented 6 years ago

Let's make stable the error handling before we proceed with fast preview, both features change the same code in mlv_video.c.

bouncyball-git commented 6 years ago

@masc4ii: I did what you asked - fast preview is in the C lib, added last parameter 'int preview' in mainwindow.c/h and put everywhere 'false', commited.

masc4ii commented 6 years ago

Thank you!

masc4ii commented 6 years ago

Woah... tried to do it. That is so difficult, I was short before going mad and I partially don't understand my code anymore :-P. Please try it out. I sometimes get crashes on import and don't know why (inside the getMlvProcessedFrame8 called from previewPicture), mostly when importing many MLV at once.

Unfortunately I can't accelerate every kind of import. Not supported is:

Selecting multiple files in OSX finder and "Open with..." (it seems, OSX sends each filename separate)
Script import (works only with one clip)

However... loading a folder of MLVs or a session from a HDD via USB2 is ultra fast now. :-)

bouncyball-git commented 6 years ago

Fixed crash here

btw do we really need following in openMlvForPreview()?

//Unload audio
m_pAudioPlayback->unloadAudio();
.
.
.
//Load audio
m_pAudioPlayback->loadAudio( m_pMlvObject );

Edit: Works without it nicely.

masc4ii commented 6 years ago

Yes, I think so. We need to unload it as long as we have the old pointer. I got crashes when not doing that.

bouncyball-git commented 6 years ago

It will be unloaded by last in selected list not preview mode active clip anyway.

bouncyball-git commented 6 years ago

The reason why I'm concerned about audio loading is that it also needs time :) and file parsing.

Edit: I tried now lots of importing/deleting clips to session list and it is fine under linux without audio. No crashes so far.

Edit: can you test this more on macos? after bug is fixed.

masc4ii commented 6 years ago

It will be unloaded by last in selected list not preview mode active clip anyway.

No, this is too late. It needs to be deleted before the first preview clip is imported. As soon as m_pMlvObject points on the new clip, Audio->unload will crash.

bouncyball-git commented 6 years ago

It is dangerous to load audio in preview mode because MLV header says there is audio in the file but preview mode parsing/indexing skips all audio frames and when checking isaudio in mlv passes ok and app will access some audio data it wil definitely crash.

bouncyball-git commented 6 years ago

No, this is too late. It needs to be deleted before the first preview clip is imported. As soon as m_pMlvObject points on the new clip, Audio->unload will crash.

We don't need Audio->unload() either. Where is the first audio object init in initLib()?

masc4ii commented 6 years ago

In the initLib doesMlvHaveAudio is false, so that is no problem. But if we don't unload audio, we have a memory leak, or what do you think!?

masc4ii commented 6 years ago

I changed it a bit... that should do the job. Audio is always unloaded now, but not loaded for preview.

bouncyball-git commented 6 years ago

Overall ( taking in account that you had to remember your code, like it happens always ;) ) great job on prevew mode!

ilia3101 / MLV-App

Fast MLV import #59