Messages

as far i can understand these fragments, the idea is to
- shoot [n] images
- detect motion between them (optical flow)
- overlay the raw images accordingly

if you have some motion now, due to vibration etc, different bayer pixels overlay now and you have a good estimate what R, G and B is at a specific "image" location.
wonder if it was meant to shift the sensor automatically (didnt hasselblad do this already using piezo?) or if the unsteady hands would deliver the required motion.
latter makes sense if you have motion *estimation* because with piezo you already know the motion.
we could capture "short 4-frame MLV files" like with silent picture and the post can be done on the pc, but...

*AFTER* someone has proven that it makes sense

Hehe, it probably can't. Question. Cr2 metadata. Is that all gathered after a picture is taken? Is that also the case with mov recordings? I mean, the wb state in liveview will record mov files with awb as seen I suppose so where is that info pending before pressing record button? Aewb task as a1ex says?

i remember that i somewhen looked into this code, but hardly can remember anything.
had some stuff in the register map on wikia, but this was just the engine registers that calculated WB data.

i am still confused how an algorithm could reliably detect the white balance, not knowing
if the image contains a blue-ish picture on a ivory colored wall, or a window on a bright white wall where you can see the blue sky through

but doesn't it pass thorugh the user's settings which are in WBAL block?

did your change your camera's WB settings since then?

./mlv_dump <mlv-file> -v > out.txt

and check your log files for WBAL block, what does it say?

recorded 128GiB videos *with* audio on 5D3 yesterday using crop_rec_4k_mlv_snd modules.
these modules were involved:

Code Select Expand


Block: VERS
  Offset: 0x000004b0
  Number: 12
    Size: 180
    Time: 514.940000 ms
  String: 'mlv_lite built 2018-07-12 23:13:23 UTC; commit f4213dd on 2018-07-03 23:10:22 UTC by g3gg0: mlv_lite: do not write all metadata again on every single chunk '
Block: VERS
  Offset: 0x00000564
  Number: 13
    Size: 80
    Time: 522.548000 ms
  String: 'mlv_meta built 2018-07-07 21:51:13 UTC; commit (no version)'
Block: VERS
  Offset: 0x000005b4
  Number: 14
    Size: 164
    Time: 530.489000 ms
  String: 'mlv_play built 2018-06-20 18:58:21 UTC; commit 0e38b89 on 2018-06-18 22:11:42 UTC by g3gg0: mlv_play: use less RAM, proper cleanup on error '
Block: VERS
  Offset: 0x00000658
  Number: 15
    Size: 180
    Time: 536.738000 ms
  String: 'mlv_snd built 2018-07-03 22:23:18 UTC; commit 9ec9c80 on 2018-07-03 22:20:19 UTC by g3gg0: mlv_lite/mlv_snd: rewrote state machine and placed WAVI writing... '
Block: VERS
  Offset: 0x0000078c
  Number: 17
    Size: 156
    Time: 554.623000 ms
  String: 'raw_twk built 2018-04-12 13:35:36 UTC; commit 6886061 on 2017-07-01 23:55:44 UTC by g3gg0: raw_twk: rework to support 16bpp input data '


mlv_meta is not public yet, used to count up take number in INFO blocks etc

100fps recording on a 6d with Magic Lantern, put on a 25fps timeline 

wow!
finally

1. First of all, thanks g3gg0 for 2018-06-26 23:36 build: sound is great, imports to DR automatically in sync.
I didn't shoot anything with sound with mlv_lite before, so i'm unsure, is it fixed, or simply works.
But, need to say, i didn't even used last mlv_dump, but "mlv_dump on steroids".
It has feature to analyse every frame for stripes.

you are welcome.
for DR i use MLVFS which works smooth in all situations i had so far.
saves a lot of time and space

And yes, 1/4000 is hardcoded in the code you have pasted (250e-6; don't remember why I wrote it like that; 1.0 / 4000 would have been the same).

250u, thats the scientist in you

this is a debugging option, being removed when things are clearly ready for end user

With the g3gg0 builds, the errors stopped, though sound is still broken. If sacrificing mlv_rec is the only way to get mlv_snd integration with mlv_lite, I'm ok with that. Maybe a memorial is in order? (^^)

to be correct, crop_rec_4k_mlv_snd *is* the branch i started initially 17 months ago.
its goal was to make mlv_snd integrate nicely into mlv_lite, so mlv_rec can get dropped.
it just wasnt finished and certainly still is not.

so there are no "g3gg0 builds" or anything else.
the memorial is "MLV"

thanks a lot for your feedback.

first of all, i missed the point that the branch "crop_rec_4k_mlv_snd" and "crop_rec_4k_mlv_lite_snd" are two different ones
so i felt safe to continue work on mlv_snd in crop_rec_4k_mlv_snd, thinking it was the right one.
my wrong, sorry.

i now manually pulled the important things from that - lets call it - bugfix branch.
now the mlv_snd module is being called right from the vsync cbr of mlv_lite, giving minimum chance for desynchronization.
(previously even the module load order could have introduced a frame delay)

@a1ex:
did i miss some important thing to graft?
as said, i want to drop mlv_rec with this branch as soon it is stable.
filmed a few TiB now with mlv_lite and close to zero with mlv_rec.

@all:
please feel free to test the latest build for audio sync issues.
the mlv_snd menu now is in the raw recording menu in case you miss it.
within that menu there is an option to configure how many frames the audio should be delayed.
if everything is as i expect it, it should be ideal at 1 - make sure you didnt accidentally set it to any other value.

thanks didnt notice that the fixes weren't merged.
will look into them and merge into mlv_snd

hi,

that sync issue was always only 1-2 frames on my tests.
felt like it is quite static, thus is added the option to mlv_snd to correct this offset.
are you sure that mlv_rec was always in sync?

about the mlrawviewer issue, i suspect that the header field for audio frames could be related as it is zero.
but being set to zero means "autodetect" and the player should detect that on its own (as with early mlv_rec headers)

edit:
please check if toggling "sync beep" in mlv_lite menu helps with the variance

Clips recorded with mlv_rec (14-bit uncompressed) still don't create a WAV with either mlv_dump or mlrawviewer.

forget about mlv_rec, i will drop it soon. at least this is my goal

Clips recorded with mlv_lite (14-bit uncompressed) and previewed with mlrawviewer playback video but still don't create a WAV. Now that I think about it, I never tested the earlier mlv_lite + mlv_snd builds to see how mlrawviewer would handle sound. Is a break in compatibility expected?

did not try this tool, mainly worked with mlvfs
there might some things be different now, yeah. block order for example.
will check tonight.

thanks for feedback

wow cool. love the feedback
would be interested what workflow they used and what could have been improved.
sometimes there are some low hanging fruits that are very helpful.

mlv_dump cannot handle this.
you could write into a raw file and delete that file afterwards, or use mlvfs and just copy the .WAV files.
i use mlvfs for everything i do with MLV files and mlv_dump only for debugging purposes

resolved, thanks. the MLV file is fine - it was a merge error in mlv_dump which caused the WAV header to be skipped.

does it work for you?

it is not part of the official ML repository.
guess there is no maintainer then who would keep it working whenever ML changed some internals.

yeah good point. could be done, have to check this.
maybe we have to add a callback but no big issue.

this proggie is his exclusive child

not correct
accepting pull requests if they fit in cleanly.
and such addition sounds if it can be done in a clean way.

That sounds like it stopped other DryOS tasks and waits for debugger commands, which may explain why it appears locked up. Just a guess.

depends how the "break" command is implemented. being in ABORT (see PC, which says DATA ABORT) is either due to accessing forbidden areas after breaking, or hmm it inserted that ABORT to stop the execution.
(not sure how the OpenOCD issues memory read commands)

guess thats due to the MPU getting out of sync and shutting down

possible, but i expected it to be closer to the PCB. hmm.